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SECTION 1 


INTRODUCTION 


1.0 Purpose 


This document specifies the environment for processes 
executing in the GCOS 8 Native Mode. The document contains 
both conceptual and cetailed information. Sections 2 


through 4 deal with conceptual level information on: 
* system gceals 
x design constraints 
* process and module staring 
* Aecsro tect control 
x performance considereétions 


Section 5s tc be Suppliecs will contain detailed information 
on: 


* The nature of the user visible extention to the high 
Level languages required to fully use the Native Mode 
(but not the exact syntax) 


* The format and contents of the files created by the com- 
pilers and assemblers 


* The calling sequencess conventions and system services 
used by the object ccde generated by the compilers 


x The JCL and ECL used in the preparation of programs for 


execution in Native Modes and the steps required for 
placing a process in execution 
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SECTION 2 


GOALS AND CONSTRAINTS 


1.0 System Goals 


From the customer point of views functionality 18 the sine 
qua non of an operating system, We haves therefore, 
attempted to identify as system goals those functions that 
will be most tmportant tc both ourselves and our customers. 
This is not to say that performance has been ignored. Per- 
formance represents the gfrimary criterion by which alternate 
designs for a given functionality are evaluated, 


These gcals have implicétions for two different levels of 
the run-time environments the macro-structure Level and the 
micromstructure level. The macro-structure of the environ- 
ment deals with the technology of program managements such 
as loadings Linking» and program library structures. The 
micromstructure of the run-time environment deals with the 
technology of program executions, such as calling sequences, 
scope of references address caiculation,s, etc. 


1.1 Pare Protection 

1.1.1 Migration Suoport 
It must be possible to migrate programs, both user applica- 
tions and Honeywell procuctss from GCOS-III to the GCOS 8 
native run-time environment, 


Programs written in high order languages must be able to mi- 
Qrate without source charges. 


It 318 desirable that assembly Language programs migrate 
without source changes. 


It is desirable that micration require no job control Llan- 
guage changes. 


These goals are important for both our customers and our- 
selves since we both have a large investment in currently 
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existing programs. The primary implication for the system is 
that all currently supported higher level Language features 
must have a functional ecuivalent in GCOS &. 


Te1.2 GCQOS-IIJI Slave Mode Accommodation 


The run-time environment must support the slave mode execu~ 
tion of GCOS-III executable file formats (Q*, H*, **, ete.). 
It also must support the following environments: 


x TSS slave environment 
x DMIV=-TP TPR environment 
* TDS TPR environment 


This objective implies support of a GCOS-III MME interface 
as defined by some choser GCOS—-III system release, 


1.1.3 Performance Relative to GCOS-III 


A given application must execute in GCOS 8 native mode with 
at Least 90% of its perfcecrmance in GCOS-III native mode when 
utilizing the same resources. 


For a given. application mix, the total throughput of the 
System must te at least $0% as good in GCOS 8 native mode as 
it is in GCOS-III native mode. 


These are very ambiticus goals» given the system overhead 
implied in meeting the virtual memory and security goals of 
the system. It is recognized at the outset that we may be 
unable to meet the 90% performance figure. 


1.2 Ease of Use and Programmer Productivity 
1.2.1 Uniform Environment 


The macro~structure of tke system should have a single per- 
sonalitys for example ECL» that encompasses all methods of 
user interaction: batchs time sharings and remote batch. 


It is very desirable that the microstructure of the system 
have a common run-time ervironment for both user and system 
software. This commonality must apply to all module interac- 
tion conventions and accesses to services. 


Of all the system goals, uniformity has the greatest impact 


on the long-term software viability. From a human engineer=- 
ing point of views unifcrmity reduces cost. From a system 
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design point of views 31tS major impact 318 in simplification 


and the cost reductions to be gained thereby. 


1.2.2 Suppart High Order Language Concentual Environments 


The run-time environment must support the implementation of 
high level language features for Languages such as COBOL, 


PL/Is Pascals Adav etc. Certain language features will 


quire explicit support ir the run-time environment, For ex- 


amples: 
* user visible address values in data space 
* autcmatic space allocation and recursion 
* process synchronization 
* tasking 
kx exception processing techniques 


x dynamic subprogram irvocation 


1.2.3 Support Very Large Apolications 


The run-time environment must be able to support applica- 
tions whose procedure space and/or data space may each ex- 
ceed a segment of 256K xords and whose total space require- 
ment does not exceed 1024 segments. The run-time environ- 
ment shculd be able to support single structures or arrays 
that exceed a segment. Such support must not require user 
preplanning cf memory maragement techniques such as program 


overlays. 


The run-time environment should be able to suprort a large 
number of filess between 200 and 1000.4 for each application. 


The run-time environment should be able to support a large 
number of connected terminalss on the order of 10000 con- 
current interactive trarsaction processing users and 5000 


simultaneous time sharing users. 


1.2.4 Support Multiole Versiaors of the Same Software Element 


The run-time environment should allow multiple versions of 
both user ard system scftware modules. This capability 45 
necessary tc support efficient software development and 


testing. 
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1.3 Technological Image 
1.3.1 Distributed Systems Architecture Support 


The run-time environment must support the Honeywell 
Distributed System Architecture (DSA). 


1.342 Virtual Environment 


The runtime environment must support a virtual address 
space that is larger than the real memory. The support 
technique will be transparent to the user. The run-time en- 
vironment must not only allow the execution of large pro- 
grams on smaller real memory but must also provide the ef- 
fective application of large physical memory. 


This goal implies that the run-time environment will use the 
virtual memory technology of the hardware. 


1.3.3 Shared Elements 


The run-time environment must support the sharing of unique. 
Instances of procedure or data among processes. 


1.3.4 System and Apolications Security 


The run-time environment must guarantee the integrity of all 
program and data within the system, | 


The run-time environment must allow user definable access 
control cver units of their applications. The access control 
mechanism will utilize the hardware segment protection capa~ 
bility. 


1.3.5 Oynamic Software Installation 
The system will support the additions deletions and updating 
of system scftware modules without system interruption, It 


1s recognized that the replacement of certain system modules 
may reqvuire system interruption. 


1.4 Cost Control 


1.4.1 Use Current Hardware 


The GCOS 8 run-time environment must utilize the current 
(NSA) hardware. Although hardware changes are possible, 
they must de Limited te field changeable items. The end 
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user is indifferent to hardware details as long as his func 
tional ard performance needs are mete 


1.4.2 Extenditle to Future Preduct Directions 


The operating system anc run-time environment should insu- 
late user interfaces anc system software from evolutionary 
hardware charges and harcware dependencies. 


1.4.3 Protect Honeywell Pricec Software 


The user manipulation of the system personality must not re- 
quire change to Honeywell delivered software modules. This 
objective assumes that the users have valid reasonss such as 
local accounting conventionss to change the personality of 
the system. The user must nots howevers, require access to 
Honeywell separately priced software products at the source 
level. 
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1.5 Goal. Summary 


The following table sumnarizes the GCOS 8 


System goals and 
classifies them as to their degree of desirability. 


Rank Reference 


Goal 
Migrate without HOL source changes must 
Accommcdate GCOS-III executable formats must 
Accommodate GCOS-III TSSs TOS» & DMIV-TP must 
Job performance at least 90% of GCOS-III must 
Throughput at least 90% of GCOS-III must 
User visible address values must 
Automatic space allocation and recursion nust 
Exception processing must 
Dynamic subprogram inveccation must 
Support large procedures must 
Support large data spaces must 
Support Distributed System Architecture must 
Support a virtual environment must 
Support shared elements must 
Provide pregram and data integrity must 
Provide user access cortrol must 
Use current hardware must 
Uniform micromstructure environment 1 
Uniform macro~structure personality 2 
Process synchronizatior o 
Support large number of files 2 
Support large number cf terminals oe 
Support multiple versicns of same module 2 
Support dynamic software installation 2 
Extendibdle to future product directions 2 
Support arrays larger than 256K = 
Protect Honeywell priced software 3 
Migrate without assembly source changes 4 
Migrate without JCL changes 4 
Tasking 4 
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2.0 Design Constraints 
2.1 Business Constraiots 


The business constraints placed upon the run-time environ 
ment are few in number yet very important. 


2.1.1 Release with SR2000 (SV) 


The multi=segment shared run-time environment must be 
released for customer use with GCOS 8 Release 2000 (5V). 
This imecses schedule corstraints on the environments, first 
for a timely definition and second for limiting its content 
to insure a timely release, 


The schedule constraint requires that the run-time environ- 
ment be consistent with that which exists in GCOS 8&8» Release 
1000 €4VX). It cannot be radically different or the sched- 
ule cannot be met. 


2eolee Minimize Conversion 


At this writings there gre interim environments in use and 
more in development: the ITP environments the ACOS environ=~ 
ment» and the PL-6 environment. Each has sharing 
mechanismss calling seqrencess and other conventions which 
differ from one to another. 


It is a constraint that modules which execute under one of 
the interim environments be able to be converted to execute 
under the new environment with a minimum of change. This is 
especially true for the modules of ITP. Modules from other 
environments are of lesser importance. 


It is a constraint that domains written according to an in~ 
terim environment coexist with domains written using the new 
environment. Adapters may be used as necessary to meet this 
constraint. It is not required that modules within a domain 
be mixed =- some from an interim environment and some from 
the new. 


2.2 Hardware Architecture Constraints 


The multi-segmented run-time environment owes its existence 


to the NSA hardware, The environment ''s design, 
functionalitys and performance is totally constrained by the 
hardware definition. The following sections descuss the 


more constraining attributes of the NSA hardware. 
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2e2e] Agcess Control 


The NSA hardware handles two types of memory spacey, real and 
virtual. Only the most frivileged modules of the operating 
System may use real memory addressing. AlLl other procedures 
must use virtual memory addressing. 


The virtual address space of the system is diviced into 512 
equal length virtual memories called Working Spaces. Work=- 
ing Spaces are accessitle to a process via eight Working 
Space Registers (WSR*'s). The contents of a WSR cannot be 
changed by a slave mode instruction. The addressability of 
a process is thus Limitec to eight working spaces. 


In NSAv a segment is a variable length subdivision of a 
Working Space. It occupies contiguous virtual memory space 
and has a hemogeneous set of attributes. These attributes 
differentiate uses of the segmentss for examples procedure 
versus data. 


The NSA hardware supports two types of segmentss a standard 
segment with a maximum of one million bytes and a super seg- 
ment with a maximum size of 64 million bytes. 


A segment is controllec by a two-word Segment Descriptor 
which specifies: 


* the particular Workirg Space containing the segment or a 
WSR containing the number of to that Working Space, 


* the base of the segment relative to a particular Working 
Spaces | | 


* the upper byte address Limit in the segments and 


* the valid access rights (reads writes execute) to the 
segment. 


As a means of access controls, the hardware requires that all 
segment descriptors reside in special segments called 
"Descrigctor Segments"s recognizable by the hardwares and 
that these Descriptor Segmentss in turns reside on special 
pagess called "Housekeeping Pages". The hardware is so 
designed that Housekeeping Pages can be written to (with 
normal instructions) only in Privileged Master Mode and can 
be read (with normal instructions) only in Privileged Master 
Mode or Master Mode. The address space of a process is thus 
Limited to those segments given to it by the Operating Sys- 


tem. Furthermores since descriptors are not storable in 
slave data spaces they are not usable as address value vari~ 
ables. | 
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All memcry addresses have two components, a segment 
descriptor identificatior and an offset within the segment. 
For normal segmentss these two components are brought to- 
gether in the NSA pointer construct. There is no equivalent 
hardware construct that points into the full extent of a 
Super segment. 


2e2ec DOmains 


The term "Demain” refers to the particular set of segments 
that are addressable by 4 process at any given moment. 


A domain consists of a static part and a dynamic part. The 
static part of a domain is defined by a special Descriptor 
Segments the Linkage Segment. There are at most 1024 
entries in the Linkage Segment. The dynamic part of the do- 
main 1s defined by the Farameter Segment and the Data Stack 
Segment. The Parameter Segment provides for passing argu- 
ments irto a domain. The Data Stack Segment provides scratch 
data space. 


A domain may inciude segments in several Working Spaces. 
During executions a domain may be augmented by passed param 
eters or by rfrivileged master mode manipulation of its Link- 
age Segment. 


A process 18 not restricted to a single domain but will gen- 
erally execute within several domains. The Linkages Parame- 
ter, ard Data Stack Secments are managed by the hardware 
when changing domains. In using the CLIMB instruction to 
change domainss howevers all of the NSA pointers in data 
space are irvalidated. Furthermores the CLIMB instruction 
makes the caller's data stack invisible to the callee. In 
combination, these constraints complicate exception 
processing and error reccvery. . 


2-5 High Order Larguage Constraints 


We have a need to suppcecrt our present-day high order lLan- 
guages such as FORTRAN, COBOL, PL/I» and PL~-6s =and also to 
Look ahead to the needs cf such languages as Pascal and Ada. 
This need corstrains the design of the run-time environment 
in that it aimplies many system functions. The following 
sections discuss those language features that will require 
explicit supfort in the run-time environment. 


2.35.1 Automatic Scace Allocation and Recursion 
The dynamics, block structured languages (Ci.se.ss all except 


FORTRAN and COBOL) provice the allocation of automatic data 
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space whenever a procedure (or block) is entered. The 
run=time environments therefores, must contain facilities to 
grow the data space of a process and must be able to identi- 
fy the current instance of the data space that is to be 
referenced by the procedure. The automatic space allocation 
technolagy is necessary to support the general recursion fa~ 
cility offered by these languages. 


2e5-.2 Dynamic Soace Allocatior by the User 


In addition to the automatic space allocation features PL/I, 
Pascale and Ada allow the user to dynamically allocate 
space. The International Organization for Standardization 
(ISO) as censidering the addition of this facility to 
FORTRAN. A variation of cynamic allocation 18s implied by the 
COBOL CALL/CANCEL facility. This Language feature implies 
the same type of run-time facility for the growth of process 
data space as is impliec by the automatic space allocation 
facilities. 


20505 YUSer_ Visible Address Values 


PL/I» Pl~-6, Pascals and Ada allow programs to declare vari- 
ables cortaining address values. These variables may appear 
Within data structures ands all languages considereds may 
point anywhere within the statics automatics or dynamic data 
space of the program. When createds these adcress values 
should remain valid throughout the life of the program. 
Since any datum may be used as an argument to another proce- 
dures the value of a aderess variable should remain useful 
across some depth of procedural calls. 


Since all of the high crder Languages support or plan to 
support cit aligned datas address values must be able to re- 
solve storage to the bit Level. 


205.4 Exception Processing 


All of the high order languages except Pascal have specified 
some facility for handling error conditions or exception 
procedures. There is no consistency in these facilities 
from language to languages. The run-time environment must 
therefore provide an exception handling technology that is 
sufficiently robust to support the full spectrum of Language 
specifications. 
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22525 Data Soace Initializaticn 


ALL of the high order languages allow the user to specify 
Initial values for some classes of datas. The run-time envi- 
ronment must contain the controls In both its 
micro=structure and its macro-structure to allow these ini- 
tial values to be realized at execution time, 


225.6 Process Synchronization 


Several of the high orcer languages support semaphore or 
Signal constructs that may be used to communicate between 
separately scheduled processes. Typically, these features 
are used to synchronize two or more processes. In 
supporting these featuress the operating system may require 
special hele from the structures of the run-time environ- 
ment . 


2e5-? Tasking 


In addition to process synchronizations some Languages pro- 
vide the ability to initiate the separate scheduling of a 
separate process. AS IN SyNchronizations the operating sys- 
tem may require special tFelp from the run-time environment. 


20528 Suborogram Invecation 


ALL of the Languages provide for the invocation cf separate- 
Ly compiled programs. Current structured programming tech- 
nology encourages the use of this facility. Therefore, the 
calling sequence technolcgy of the run-time environment will 
be an Important determinant of System performance, The 
technology must also supfort the various language specifica- 
tions for passing arguments by reference or by value. The 
ANS COBOL specification expands the problem in two ways. Its 
CALL/CANCEL facility allows the dynamic associations invoca- 
tions and disassociaticn of subprograms whose names are 
supplied at execution time. This facility will require spe-~ 
cial run-time environment techniques in both program invoca-~ 
tion and prcgram packaging. The COBOL SORT/MERGE facility 
allows the user to estaclish procedures within his program 
that are to be used as comroutines by the system software 
that supports the sort or merge. The run-time environment 
must solve the programs packaging problem posed by such 
comroutines and must previde an extremely efficent invoca- 
tion technolcgy for them. 
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SECTION 3 


DESIGN OVERVIEW 


1.0 System Conceots 
1.1 Concentual Mocel 


The operating system 31s cescribed in the accompanying GCOS 8 
ARCHITECTURE document as a layered construct at the center 
of which resides an inviolate system kernel. That kernel 
provides the hardware dependent functions and those house- 
keeping functions that require privileged master mode execu- 
tion. System shared software is closely associated with the 
kernel. This software prcecvides the common service functions 
that are usec by all userss regardless of their interface to 
the system. The outermost layer of the system cgrovides the 
end-user interfaces that define the personalities of the 
System. 


The system is also planned to be naturally adaptable to the 
Distributed Systems Architecture. Support services such as 
session control and workstation management will be supported 
In the system shared sortware. 


1.2 System Organization 


Both the construction and utilization of the system are 
organized around the concept of segmentation. In terms of 
constructions segments may be considered singly or may be 
organized into domains. These single segments and domains 
ares, in turns organized into Working Spaces for the sake of 
execution. 


Utilization of the system is organized around the concept of 
"“yrocess”". A process is a triplet composed of an execution 
streams, its associated détas and the processor that is doing 
the execution. The execution stream may involve several pro- 
cedure segmerts and/or dcecmains and/or Working Spaces in suc~ 
cession. It may also invelve many data segments in disparate 
domains and/ecr Working Spaces. 
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The organization of the run-time environment has two differ- 
ent levels, the macro-structure level and the 
micromstructure level. The macro=structure of the environ= 
ment deals with the technology of program managements such 
as loadings Linking» and program library structures. The 
micromstructure of the run-time environment deals with the 
technology of program executions such as calling sequences, 
scope of references address calculations etc. 
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2.0 System Macro=structure 
2.1 The Virtual Environment 


The virtual environment is defined by the segments available 
to the system. The segments are organized into Working 
Spaces. The virtual environment available to a process is 
limited to those Working Spaces that are addressable through 
the Working Space Registers (WSR's). The virtual memory lo- 
cal to the process itself, that iss its segments and 
domains» are rooted in a single Working Space. That Working 
Space is accessed via WSR7. The other WSR's are loaded to 
provide the process access to system Level and shared do- 
mains and segments. 


All Working Spaces have the same general structures although 
all types of segments de not exist in every Working Space. 
This consistency of structure across Working Spaces permits 
easy access to data that 1s canonically located within the 
Working Space, 


2ee.c The Shacing Mechanism 


Resource sharing is an important objective of GCOS 8. How- 
evers this sharing of resources must be balanced with anoth- 
er objectives, security. The criteria for security are thats 
without proper authoritys no user should be able to: 


x retrieve another user's data or programs 

* manipulate another user's data or programs 

x deny the resources of the system to another user 

These criteria imply that resource sharings while desirable, 
must be tightly controlled. The system must be protected 
from the external users and the users from each other, 

This isolation is accomplished at four Levels: 

1. Working Space Level = a Working Space is addressable 
only if the Working Space Number is loaded into one of 
the Working Space Registers for the process. 

2e Page Level ~- to reference a pager, it must be mapped 
inte the page table and the reference must be consis- 
tent with the housekeeping and write protect flags in 
the Page Table Word. 

3. Domain Level —- to reference a datums a segment 


descriptor for the segment containing the datum must be 
accessatle in the demain. 
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4. Segment Level -=- the data reference must be within the 
segment's bounds ard must be consistent with its type. 
fieid (cata, descrirfters or entry) and permission flags 
(reads writes executes ett... 


When two or more processes share a Working Spaces sharing 
takes three forms, domain instance sharings domain pattern 
sharings and segment sharing. 


2e2.1 Domain Iostance Sharing 


The first form of sharing is the sharing of a unique in- 
stance of a domain. There is one Linkage Segment for the 
shared domain and all crocesses CLIMB to the domain via 
identical entry descriptcecrs to that single Linkage Segment. 


A consequence of domain instance sharing is that all static 
segments of the domain are shared. There are no process lo- 
cal secments accessible to the shared domain other than 
those passed as parameters of the CLIMB. 


2.2.2 Domain Pattern Sharing 


The second form of sharing is the sharing of a pattern or 
template for a domain. A skeleton Linkage Segment is used 
as a pattern to create nultiple occurrences of the domain. 
Each occurrerce of the comain is created by allocating one 
or more data segments ir the invoking domain and inserting 
them into the skeleton Linkage Segment. The resulting Link- 
age Segments i.@. domains will embrace shared procedure 
segments local to the new domain and data segments in either 
the caller's Working Space or in the shared Working Space or 
both. 


This type of sharing is useful when the domain must include 
both shared and process Local segments. The shared domain 
pattern includes the shared segmentss but each occurrence of. 
the Linkage Segment is given separate instances of the local 
segments. Since the one pattern is always used to construct 
the domain occurrencess all the Linkage Segment occurrences 
have the same layout or cefinition. 


22.35 Zegment Sharing 
The third tyre of sharing is segment sharing. In this cases 
individual segments are shared among multiple domains. This 
type of sharing has a number of restrictions which, when 
mets allow very efficient operation. 


The restrictions which agply to shared segments are: 
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1. If the segment is a procedure segments it may access 
descriptors in the comain's Linkage Segment or Parame~ 
ter Segment only when they are in fixeds canonical lo- 
cations or when pointers (NSA pointers) are passed as 
arguments of a call. 


2e Procedure segments must be pure. 


3. Data segmentss if impures must be gated by means of a 
monitors ie@.s access to them must be through a monitor 
procedure. 


2.3 working Soace Packaging 


2ede-!1 Overview 


The following figure depicts the steps required to prepare a 
program for executions beginning with compiling the program 
and ending with the mapfring of the program into a Working 
Space. 


A compiler cr assembler produces an A-~unit from the source 
program. The A~unit contains the initial segment contents, 
both code and data. 


If desired, multiple f-units may be combined into one 
A-unit. The result of this merging is that segments with 
compatible attributes are combineds thereby reducing the to- 
tal number of segments required. 


Nexts one or more Awunits are input to the Brunit Builder 
which ccembines them into domainss as specified by the direcm . 
tivess to preduce a Brunit. The Brunit is a file containing 
a Working Space image cf the domains and their segments. 
Optionallys an existing Erunit may have one or more Amunits 
added, deleteds or replaced. 


The Working Space Assignment function assigns a Working 
Space Number and a Working Space Register to the Brunit. Ex- 
ecution commences when the process structure is added to the 
Working Space by the Process Initiator and the root domain 
of the process is dispatched. : 
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2.3.2 Packaging Elements 

Cedele!] Arunit 
An Aw-unit is a file which contains the object representation 
of an indegendently ccmpiled or assembled program unit 


Ce.ger a PL/I external procedure or a COBOL program). The 
creation of an Awmunit is not a privileged operation. All 
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~ 


compilers and assemblers produce an Awrunit aS output. An 
Am~unit contains the follcwing types of information 3: 


x A~unit icentificatior 

x segment cefinitions and references (SEGDEF/SEGREF) 

* domain definitions and references (CENTDEF/ENTREF) 

x symbol definitions and references (SYMDEF/SYMREF) 

* object text 

* debug schema 

* relccaticn informaticn 

* resource requirements 
Before a prcgram represented by an Arunit can be executed, 
7t must be combined to form one or more Breunits by the 
B-unit Builder. 

2e.5022.2 Brunit 

A Brunit is a file which contains a representation of one or 
more dcmainss including procedures datas and Linkage Seg- 
ments for each domain. B-units are produced by the Brunit 
Builder from one or more Awmunits. The B-unit Builder is 
able to "upcate”™ an existing B-unit by adding or replacing 
Am~units. A G-unit contains the following types of informa- 
tion : 

* Brunit identificatior 

* skeletal page table (describes virtual space assignment) 

* one cr mcre domains 

*® Linkages procedures and data segments for each domain 


* Domain Directory of all domains CENTDEF's) 


x Global Segment Directory for all segments known exter- 
nally to the Brunit 


* directory of unresolved segment references (SEGREF) 
* directory of unresolved domain references CENTREF) 
Note that a Beunit does not contain any process structure 


(@.ges hardware stack segmentss SSA segmentss etc). All 
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references to segments and domains outside the B-unit are 
left unresolved. | 3 


Cese2ed Lidraries 


It is necessary at times to reference groups of files as a 
unit. For examples, a group of SB8-units may be assigned to a 
Working Space. This is accomplished by referencing a li- 
brary containing those Brunits. A Library is implemented as 
a directory in the File System. This directory contains 
only filess no subordinate directoriess and all these files 
are of the Same type (@4Gese Brunits). Since the files are 
of the same type and have common attributes such as control 
interval sizes, access to these files can be optimized, 


e505 Compiling 


The compilation process employed for the GCOS 8 environment 
is the cconvertional one tin which source programs in the form 
of text files are processed to produce object modules in the 
form of Amunitss ands og¢tionallys a report of the compila-. 
tion process in the form of a Listing. Such Amunits usually 
require the support of runtime libraries for their execution 
and may require other userm~supplied Aw~units for their execu- 
tion. 


A typical Amunit will contain two or more segments (Cat least 
one instruction segment and one data segment). Hocwevers, some 
Language constructs or implementation techniques may produce 
large numbers of segments. 


22524 Arunit Merging 


The merging cf A-units is combining the segments of two or 
more A-units into fewer total segments. The segments with 
compatible attributes are combined and relocation is 
performed on the segment references. Thus ali of the proce- 
dure segmentss one for each Amunits might be combined to 
form only one procedure segment. The output of the A-unit 
Merger is a new Awunit that contains the segments of all of 
the input Awmunits. 


Co3-5 Brunit Builder 


The Brunit Builder oprecduces a Br-unit from one or more 
A-units anda set of cirectives that describe now these 
A-units are to be combined into domains. The Brunit Builder 
creates a Lirkage Segment for each domain and assigns virtu- 
al space to each segment of the domain starting at a conven- 
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tional base address. Domain and segment references are re- 
solved where possible. A page table that describes the 
assigned virtual space is also created. 


The Br-unit that is produced includes a Domain Directorys a 
Global Segmert Directorys and a directory of unresolved seg- 
ment references. The CSomain Directory contains an entry 
describing each domain ir the Br-units while the Global Seg- 
ment Directory contains an entry describing each segment in 
the Beunit which may be referenced from outside the Brunit. 


Sufficient irformation is kept in the Beunit to permit the 
additions deletions or replacement of one or more A-units in 
an existing Brunit. 


No shared libraries are referenced in order to create the 
Brunit. ALL references outside the B8-unit are left 
unresolved. References to external domains result ina dy- 
namic Linking descriptor that references the name of the do- 
main. Segment references result in segment descriptors with 
the "missing segment" attribute. These dynamic references 
will be resolved by the Cynamic Linker at process initiation 
time. 


2.5.6 Working Space Structure 


Alt Working Spaces have the same general structure. At the 
beginning of each Working Spaces offset zeros 1S a 
descriptor segment which serves as a directory to the Work- 
ing Space. This Working Space Unique System Header (WSUSH) 
has the same canonical definition for each Working Space, 
regardless of the function for which the Working Space is 
employed. Fer a given Working Spaces not all entries of the 
WSUSH are valid (Cesger ttre entry for the SSA Segment is not 
valid for a shared Working Space). Invalid entries contain 
null descriptors. 


The segments Located via the WSUSH fall into two categories: 
those required for all Working Spaces regardless of their 


function and those required only for Working Spaces that 
instantiate a processes. 


2ete501 Segments Fequired in All Working Spaces 
Alt Working Spaces require at least the following segments: 


* the Domain Directorys a table that defines every domain 
in the Werking Space. 
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x the Global Segment Directorys a table that defines every 
global segment (i.e@.s every segment known externally) in 
the working Space. | 


* a directery of all the dynamically allocated segments. 


* the Page Tables a variable length segment containing the 
page table entries fer the Working Space. 


* the PAT segments a variable length segment used to con- 
tain the Peripheral Allocation Tables (PATs) for the 
Working Space. | 


* the DCW buffer, a segment used for DCW List storage for 
paging I/O» process swapping I/Os SYSOUT I/Os etc. 


22534622 Segments Required. in Froecess Working Spaces 


In addition to the segmerts required in all Working Spaces. 
those Working Spaces usec to contain processes also require 
at least the following segments: 


x the Exception Procedure Entry Descriptor Segment 
CEPEDS), a descriptor segment containing the entry 
descriptors to the exception handling procedures for the 
defined exception corditions, | 


* the User's Linkage Segment Descriptor Segments a vari~. 
able length descriptor segment containing the Linkage 
Segments for all user domains in the process. 


* the Safestore Stack Segments a variable tlength segment 
used to store registers when changing domains. 


x the Argument/Parameter Stack Segments a variable length 
segment used to pass arguments between domains. 


x a segment used by the Dispatcher. 


* the SYSCUT segments used to collect the system output 
records. The sizes, contents and location of this seg- 
ment vary with the number of SYSOUT Lines. 


* the SSA Data Segments a segment containing control in- 
formation equivalent to the GCOS-III control information 
contained in the Slave Service Area (SSA). 


x the SPA Data Segments a Segment containing control in- 


formatior equivalent to some of that contained in the 
GCOS-III Slave Prefix Area (SPA). . 
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* the Process Control Block (PCB), a segment containing 
information necessary to control the process. 


2.5.7 ASSigning.a B-unit to. a working Space 


A Brunit may either be gflaced in executions that is» become 
aprocesss or be a shared Berunits, that is», be referenced by 
or executed by many processes. In either cases the Brunit 
must be assigned to a Werking Space. The function of Work- 
Ing Space Assignment is not to load Brunits into the virtual 
memory af the Working Spaces but to associate the Beunits 


with the Working Scace. This 78 accomplished by 
constructing a Domain Directory and a Global Segment Direc- 
tory in the virtual memory of the Working Space. These 


directories completely cefine all domains and global seg- 
ments contained in the S8~unit or Beunit Library. These 
directories are searched by the Dynamic Linker when 
attempting to resolve a reference to a domain or segment. At 
the first reference to a domain the Be-unit containing the 
desired comain or segment will be loaded. 


The input to the Working Space Assignment function is either 
a single Brunit or a Brurit Library that is to be assigned a 
Working Space. The resource requirement information is read 
from the Brunits and is used to create a backing store file. 
The Domain Directory anc Global Segment Directory are read 
from each of the Brunits. These directories are combined 
and are Located canonically in the Working Space. 


After completion of the Working Space Assignment steps a 
Skeletal page tables ODcmain Directorys and Glcbal Segment 
Directory exist in virtual space and a backing store file 
will have been created fcr the Working Space. An available 
Working Space Number will have been assigned. The assignment 
of a Working Space Register for the Br-unit will depend on 
whether the Working Space is to be shared or is to become 
the root of a process. 


223-8 Working Soeace Register Usage 


The fundamental sharing mechanism in GCOS 8 is the sharing 
of domains and segments in shared Working Spaces. By 
mapping Working Spaces into the same virtual address space 
of a set of processess the contents of the Working Spaces 
may be shared among the cfrocesses, 


Within GCOS &, WSR? is reserved for all process local infor- 
mation. The other WSR's are used for shared software and 
data. The smaller the WSR numbers the more global the 
sharing. The provisional assignment of WSR's and sharing is 
as follows: 
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WSR Number Usage 


Operating System Hard Core 

Operating System Hard Core 

Operating System Slave Mode 

Priced Software Products 

Installation (Site) Specific Software 
User Shared Software | 
Workstation Local 

Process Local 


NOW & Wr =| © 


The mapping is performed by the WSR contents. A Working 
Space 1s shared if two or more processes have its Working 
Space Number in the same WSR. When a Working Space is 
shared, it must be shared by using the same WSR in all the 
sharing processes. This restriction is due to the fact that 
references to the WSR appear in the Working Space itself. 
Each Segment descriptor contains a value for the WSR 
containing the segment it describes. 


Furthermores once two processes have established the Sharing 
of a Working Space in some given WSR», all of the more global 
WSR's must have matching values for the two processes. 


The Working Spaces referenced by WSRO through WSR are 
Shared by all processes in the system. WSRS is reserved for 
customer controlled sharing. WSR6& contains the same value 
for all processes of a workstation. The content of WSR? is 
unique tc each single precess. 


2.4 Process Execution 
(2.4.1 Process Initiation 


The Be-unit destined tc become a processr having been 
assigned to a Working Spaces now only requires the addition 
of the process structure to be executable. The Process 
Initiator assigns a process numbers builds the process 
structure (e.ges hardware stacks,» SSA segments process con- 
trol blocks, etc.) and lcads the Working Space Registers for 
the process. | 


The Beunit itself has still not been loaded in virtual memo- 
rye Only the “definition” of the Brunits in terms of the 
names of its domains ard global segments and its process 
structure have been loaded. 


Finaliys, the Process Initiator executes a CLIMB instruction 


to the user entry point. Since the Berunit containing the 
user's domain has not yet been loaded, this CLIMB generates 
a dynamic Linking fault. The Dynamic Linker resolves the 
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reference and the process begins executing in its root do- 
main. 


2064.2 Dynamic Linking 


The Dynamic Linker 18s invoked to resolve references to both 
segments and domains. This involves utilizing the search 
rules that govern the orcer in which the Working Spaces are 
searched, lccating the desired objects and replacing the 
unresolved reference with the appropriate entry or segment 
descriptcr. 


Linking to shared domains occurs dynamically while the proc- 
ess 1S In executions while linking to shared segments occurs 
at the time when the E-unit containing the reference is 
loaded into virtual memcry. References to shared segments 
are resolvec by locating the segment and storing the 
descriptor of the segmert in the referencing domain (1.40.2 
Linkage Segment). | 


2.42221 Search Rules 


Whenever a dynamic reference to a segment or domain occurs,s 
a search must be conducted in an orderly manner through the 
virtual space addressable by the executing processs that is, 
through the working Spaces loaded behind the WSR's for that 
process. The search begins with the Working Space 
containing the instruction segment of the executing domain 
and proceeds sequentially through more global (decreasing) 
values cf Working Space Register number. For examples, if 
while executing a domain whose procedure segment is behind 
WSRS and a dynamic lLinkirg fault occurss then the search for 
the referenced domain besins with WSRS and continues in se- 
quence throush WSR4, WSR3s4 WSR2e WSR1Iv and WSRQ until the 
desired domain is found. 


At times it 7s desired to reference a domain at a tlesser 
scope of sharabilitys that iss a domain behind a higher val- 


ue of WSR. This functicnality is useful tn the support of 
exception processings user exit procedures, etc. This 
“outward” reference will be allowed only when explicitly 
declared on the reference. In this cases the dynamic 


Linking descriptor contains a field which specifies the de- 
gree to which the outward reference 1s permitted. 


2.4.2.2 Dynamic Linking to Domains 


Each Working Space contains 2a Domain Directory that 1s 
Located canonically via the WSUSH and describes the domains 
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of the working Space. Each entry in the Domain Directory 
contains at least the following informations: 


* domain name 
* name of E-unit cotairing the domain 


* entry descriptor to comain (valid onty if the Beunit has 
been activated) 


* domain type Cunsharecs shared domains shared domain oc- 
currences etc.) 


* count of outstanding references to the domain 


When a dynamic Linking fault 1s generated by the execution 
of a CLIMB instruction through a dynamic Linking descriptor, 
the Dynamic Linker is irvoked to resolve the domain refer~ 
ence. If the domain 1s not founds the Dynamic Linker re- 
turns anerror status and exception processing commences. 
If the name is found ard the B=~unit containing the domain 
has not been lLoadeds then the Beunit is activated. The ref- 
erence to the domain is then resolved depending upon the 
WSR*'s behind which the invoked and invoking domains are 
found and upen the domain types. 


If the referenced domain uses unique domain instance sharing 
and the referenced domain has been found behind a more glob- 
al WSR than the referencing domains then the dynamic Linking 
descriptor is replaced with the actual entry descriptor to 
the shared domain and the CLIMB is rewmexecuted. 


If the referenced domain uses unique domain instance sharing 
but has been found behind a less global WSR than the 
referencing domains then the CLIMB is completed without 
replacing the dynamic Lirking descriptor in the referencing 
domain. 7 | 


If the referenced domain uses domain pattern sharings the 
prototype Lirkage Segment is copied into the caller's space. 
Any local segments are created dynamically and initialized. 
Then the original dynamic Linking descriptor in the calling 
domain is replaced by an entry descriptor to the newly 
created Linkage Segment and the CLIMB 1s rew~executed. 


204-2435 Oynamic Linking to Segments 


Each Working Space contains a Global Segment Directory that 
is Located canonically via the WSUSH. This directory de- 
scribes the segments of that Working Space which are exter- 
nally visible (Ci.se.wr Shared among S-units). Each entry in 
the directory contains at least the following information ; 
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* segment name 
* name of B-unit containing the segment 


xk segment descriptor (valid onty if the Beunit has been 
activated) 


x count of outstanding references to the segment 


Ife when loaded into virtual memorys a Brunit contains any 
unresolved references tc segmentss then the Dynamic Linker 
1s invoked to resolve thcse references before the B-unit is 
executed. The Dynamic Linker employs the search rules to 
determine the Working Spaces to be searched and then 
searches the associated Global Segment Directories for the 
desired segment name. If the name is not found behind a 
more global Working Space Registers a descriptor with the 
“missing segment” flag set is returned. If the name is 
found and the Beunit cecntaining the segment has not been 
loadeds then the Brunit 1s activated. Finallys the 
descriptor framing the desired segment is returned. 


224.3 Brunit Activation 


A B-unit is activated in response to a call from the Dynamic 
Linker when attempting to resolve a reference to a segment 
or domain. The referenced Brunit 1s assigned an origin or 
base for data segments and another for descriptor segments. 
All of the descriptor segments for the Brunit are then 
Loaded in virtual memory. 


ALL of the segment descriptors and entry descriptors in the 
Beunit were initialized with a vatue for the Working Space 
Register (WSR) when the Brunit was created. If that value 
for WSR is not the same as that assigned by the Working 
Space Assignment functions then the WSR values in the 
descriptors must be adjusted to the correct value. If the 
base virtual addresses for both data and descriptors 
assigned by the Beunit Activator do not agree with those 
assigned by the Beunit Builders then the base virtual 
addresses in the descriptors must also be adjusted. 


The page table for the horking Space is updated to reflect 
the addition of the paces for the Beunit and the backing 
store file may be initialized at this time. The real memory 
working set is also adjusted to reflect the addition of the 
Beunit to the Working Spaces. The Domain Directory and the 
Global Segment Directory are updated to reflect the actual 
virtual memory address of the domain and segment (1.@.s en- 
try and segment descriptcrs) in the Beunit. 
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Finally» the Beunit Activator must determine whether this 
B—unit itself has any urresolved segment references. This 
is accomplished by accessing the table of unresolved segment 
references in the B-unit. For each unresolved reference, 
the Beunit Activator catis the Dynamic Linker, Thiss in 
turns may cause other Be-unitss the ones containing the 
referenced segmentss to te activated. When this process is 
completes, the Beunit activation has been finishec, 


Note that references frem the Brunit to segments have now 
been rescived. However, references to other domains outside 


the Beunit have not. Demain references still exist In the 
form of dynamic Linking cescriptors. 


2.9 Loterc-Process Communicaticn and Synchronization 


The Process Synchronization facility of GCOS & exists to 
perform two tasks: 


* maintain the integrity of shared datas and 


* synchronize the execrtion of parallel process. 


A more specific discussion of these concepts 1s to be 
supplied. 
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3.0 System Micro-structure 


The micromstructure of tke run-time environment consists of 
the conventicns fors 


* intra-domain calling sequences 

* Inter-domain calling sequences 

* stack hardling 

* register allocation 

* excection processing 

k Interrupt handling 

x conditior handling 

* Inter-process synchrcnization 

* operators 

* debugging aids 

* segment structure anc binding 
3.1 Standard Segments 


Each dcomain contains a number of standard segments. They 
are: | 


x Linkage Segment 

* Parameter Segment 

* Argument Stack Segmert 
* Software Stack Segmert 
* Procedure Segment(s) 

* Data Segment(s) 


x Operator Segment 


3.2 Software Stack Conventions 


Each domain has a Software Stack Segment for argument pass- 
ing and subroutine lLinkace within the domain. The Software 
Stack Segment may be a static part of the domain or it may 
be dynamically obtained from the Data Stack. If it is in the 
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Data Stacks the entire amount required by the domain 


allocated upon entry. 


1s 


The descriptcr framing the complete Software Stack segment 
is saved in location C cf the Argument Stack and in a con- 
ventional ODR. The associated pointer register always points 


to the base of the currert stack frame. 


There are twe kinds of stack frames in the Software Stack 


a root frame and abasic frame. 


3.2.1 Root Frame 
There is one root frame in the Software Stack and it 
root frame ccntains the following information: 
* a fault recursion count 
* a pointer to the exception processing array 
* the base of the current stack frame 


* the total size of the stack 


*« the location of all cefault enabled conditions, and 


* the location of the rext available stack frame. 


a> <p 


1s al- 
ways the first frame. It is created on domain entry. 


The 


The root frame is updated when each internal call is made, 


1e@.f when a basic frame is created or released, 


3.2.2 Basic Frame 


There are many basic frames in the Software Stack. A basic 
frame is created when a subroutine 1s calleds ewger external 


proceduress CN CONDITION handlers. 


A basic frame contains a fixed area for control information 
and a variable length grea for parameter passing and the 


subroutire's (block's) artomatic storage, 
The information consists of: 

* register safe store (optional) 

* control information 

* pointers to input and output parameters 


* oointers to argument descriptions Coptional)s, and 
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* automatic storage. 


It is important to note that the parameters passed in the 
stack are the addresses cf the data items. In GCOS 8,4 these 
addresses are NSA pointers having a 24-bit bit address and a 
12-bit segmert identification. 


3.3 Qperators 


Included in every domain is a segment reference to a shared 
procedure segment contairing operators. Operators are short 
procedure sequences which perform some support service to 
the compilec procedure. Among the operators are code se= 
quences to handle intra~cdomain procedure calls (between seg- 
ments of the domain) and exitsSs various arithmetic 
functionss cperating system call adapters (PMME adapters) 
and inter-domain calls ard returns. 


Operators are invoked ty an inter=-segment (cross~segment) 
transfer to the correct entry point in the operator segment. 


The subroutine Linkage operators perform alt the stack 
handling and environmert preparation required during a 
subroutine call. The preparation of arguments is done be- 
fore the operator is invcked. 


3.4 Lotra-dorain Calling Sequence 


The calling sequence used within a domain establishes con- 
ventions for how the parameters are passeds how the Software 
Stack is hancleds how the return linkage is handled and how 
the callee's environment is created, 


3.4.1 Subroutine Linkage 


The actions that are recuired for subroutine invocation are 
divided between the calling procedure and the interface op- 
erator. The calling procedure prepares the arguments and 
argument descriptions while the interface operator handles 
the stack, does any register saving and creates the return 
Linkage. 


3.4.2 Parameter Passing 
Parameters are passed frem the caller to the callee by pass- 


ing a list of addresses of the parameters plus (Coptionally) 
the addresses of their argument descriptions. 


DESIGN OVERVIEW | 3-19. March 31,4 1980 - 15:20 


Since the adcresses are ASA pointers, the descriptors of the 
segments which form the comain must be in either the Linkage 
Segments the Parameter Segment or the Argument Stack. Sub- 
ordinate descriptor segments cannot be used. 


Note that nO parameters or addresses. are passed in 
registers. This insulates one subroutine from the ODR 
and/or register conventicns of another, 


3.5 Program Segment Structure 


The output cf a compiler is an A-unit containing procedure 
and/or data segments. A procedure segment consists of 
generated coders a pointer areas and one or more entry areas. 
The generated code is ali IC relative, i.e. it is floating 
code. 


Except for entry pointss there are no references to a proce- 
dure segment from outside the segment. Constants are 


packaged within the procedure segments thus the minimum per- 
missions for the segment are Read and Execute. 


3.5.21 Pointer Area 
The pointer area is an area containing all the NSA pointers 
needed by the procedure for references to other segments as 
shown in Figure 3€a). The procedure loads ODR's (via LDP1 


Instructions) from this area when necessary. All references 
to the pointer area are IC relative. 


Sedat Entry Point structure 


Associated with each entry point to a procedure segment is 
data which defines: 


x The ASCII name of the entry point 

* The number of parameters expected 

* The language and version which created the procedure 
* The amourt of automatic (stack) storage necessary 


* The location of the executable procedures, the pointer 
area and debugging irformation (debug schema). 


This data is tentatively Located at negative offsets rela- 
tive to the entry point. 
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| Entry Point Data ] 
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| 
| 
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1 Entry Point Data | 
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Point I | 
1 Procecure | 

| And Ccnstants i 

/ | | 
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Figure 3(¢a) Frocedure Segment Layout 


3.5.3 Procedure Segment Merging 


Binding a precedure segment into a domain involves resolving 
the inter-segment references contained in the pointer area. 
This will cause the SEGID and the 24-bit address fields of 
each pointer to be adjusted as the Linkage Segment of the 
domain is established. Only the pointers which refer to the 
Linkage Segment are adjusted. Those which refer to the Pa- 
rameter Segment and Argument Stack do not require adjustment 
(relocation). 


Multiple procedure segments may be merged into one segment 

during the binding process. This is possidle when their 

combined size is less than 256K and their attributes (Cexe- 
cutes read) are identical. Since the generated code 1s 

floating codes, two procedure segments can be combined into 

one by concatenating them and adjusting the inter~-segment 

references of all segments in the domain. 
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Figure 3b) Merged Procedure Segments 


3.544 Data Segment Merging 
Multiple data segments may be merged into one segment during 
the binding phase. This 18 possible when their combined. 
size is tess than 256K and their attributes (reads writes 
cache—bypass) are identical. | 


References tc the segmerts which have been merged must be 
adjusted by relocating the NSA pointers which form the ref- 
erences. Similarly, references from one data segment to an- 
other via NSA pointers (which arise from pointer data types) 
must be adjusteds both ir their SEGID field and their 24-bit 
address field. 


3.6 Exceotion Processing 
| Excepticn processing includes the handling of: 
x ON CONDITIONS 
x faults 
* interrupts 
Each is handled by a cordition handler unique to the event. 


ON CONDITION events may be detected synchronously during 
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normal processing or they may be detected asynchronously by 


a hardware fault. Another asynchronous”) event 


terrupt from one process to another, 


which 
handled the same way 18s é "software interrupt"»s i.@e- 


is 
an in- 


The things which are used in handling exception conditions 


ares 
* The Excerction Processing Pointer Array (EPPA) 


* The CN CONDITION hanclers, 


* The Excerction Processing Entry Descriptors (CEPEDS) 


3.6.1 Exgceotion Processing Pointer Array 


Associated with every domain 18S an array which contains 
pointers to the asynchronous event processing routines for 
the domain. This array is located by a pointer in location 


O of the stack segments which is In turn Located by 


descriptor ir Location 0 of the Argument Stack. 


a 


The EPPA may be in its own segment or may be part of a 
larger segment. The EPPA contains NSA pointers to the pro- 


cedures which handle 
* The hardware faults overflows, lockups etc.) 
x Software interrupts 
* GELCOP detection 
x Wrapup 


3.6.2 Exception Processing Entry Descriptors 


To be supplied. 


32.6.3 QN. CONDITION Handlers 


To be supplied 


32644 Exception Processing Flcw 


To be supplied. 
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SECTION 4 


REALIZATION OF GOALS 


1.0 Introduction 


This section describes hcw the proposed environment does or 
does not meet the goals that were stated in Section 2. The 
summary table from Section 2 is reprinted with a column 
which indicates whether the proposed design will meet the 
goal» whether it will not meet the goals or whether its re- 
sponse to the goal still needs to be determined. In those 
cases where a simple answer will not suffices the column 
contains a reference to a Succeeding paragraph in this sec- 
tion. 
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2.00 Goal Realization Summary 


Goal 


Migrate without HOL source changes 

Accommodate GCOS~III executable formats 
TOS» & DMIV=-TP 
of GCOS-III 


Accommodate GCOS-III TSS, 


Job performance at least 90% 


Throughput at least 90% of GCOS-III 


User visible address values 


Automatic space allocation and recursion 


Exception crocessing 


Dynamic sutprogram invccation 


Support large procedures 
Support large data spaces 


Support Distributed System Architecture 


Support a virtual environment 


Support shared elements 


Provide program and data integrity 


Provide user access cortrol 


Use current hardware 


Uniform micro=structure environment 
Uniform macromstructure personality 


Process synchronizatior 


Support large number of files 


Support large number of terminals 
Support multiple versicns of same module 
Support dynamic software installation 
Extendible to future product directions 
Support arrays larger than 256K 

Protect Honeywell priced software 
Migrate without assembly source changes 


Migrate without JCL changes 


Tasking 
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Rank Response 


must 
must 
must 
must 
must 
must 
must 
must 
must 
must 
must 
must 
must 
must 
must 
must 
must 


& & & WWW A fh 8 MM MT 


March 31.4 


yes 
yes 
yes 
3.0 
Sa0 
yes 
yes 
TBD 
TBD 
yes 
TBD 
yes 
yes 
yes 
yes 
yes 
yes 
yes 
yes 
yes 
yes 
yes 
yes 
yes 
yes 
no 
TBD 
4.0 
4.0 
TBO 


1980 


13320 


3.0 System Performance Estimates 


Two types of performance analysis were done. The first 
analyzed programs executing in an existing multi=segment en- 
vironment using four performance case studies. The programs 
were analyzed to determine their instruction mix and then, 
from the mixess the perfcrmance of the programs relative to 
their execution on the ursegmented GCOS-III was estimated, 


In the second analysis» the object code of two programs 
compiled for GCOS-III was modified for the multi-segment en- 
vironment and analyzed relative to the original versions. 


It 1S important to note that many factors in addition to the 
execution environment affect the performance of the system. 
The analyses presented in this section do not predict the 
overall GCOS 8 performance relative to GCOS-III. Rather the 
numbers state that for a given number of instructions 
executeds the GCOS 8 performance will be b times the 
GCOS-III performance, Since b is Less than ones using the 
multi-segment capability of the NSA hardware in the GCOS 8 
environment effectively cemrates the CPU. Other factors not 
included in this analysis such as the differences in the 
Supporting run-time subroutines, the operating system ser- 
vicess etc.es will significantly affect the total performance 
of Gcos &. 


3.1 Performance Case Studies 
References : 


1) Irelands R.oJs and OtlLaughlins, J.T.- 
"Virtual Unit Instructionss Timess and Counts", 
Analysis Note =-— 182, 
February 14% 1980. 


2) Browns FeMae 
Vuewgrach tables on NSA instructions dated 
January 28, 1980. 


3) Ireland.» ReJesr private communications on NSA timing, 
February 18% 1980. 


4) Krasnys Lee 
"Virtual Unit Instructions on CP-6", 
March 11, 1980. 


The interesting combinations of hardware and operating sys~ 
tems are presented in the following table, using GCOS III 
performance on the 66&0 without the NSA option as a 
baseline. 


REALIZATION OF GOALS 4=3 March 31, 1980 - 15:20 


Gcos III GCOS 8 GCOS 8 
Accommodation Native 


6680 X aX b X 


EAD AD NN A ND = “NE A ~<a OE EN EE AOD RS GUN -~OR AND EN DAO ~~ ~TED OUD “UD 


The coefficients "a" and "“b™ represent the performance fac- 
tors. Due to the pipelire structure of ADP, it is impracti- 
cal to cerive the ADP coefficients without simulation or 
measurement. Therefores this study only attempts to derive 
values for the 6680 coefficients "a" and "b", 


A number of case studies are presented, some representing 
static analyses of various programs and some representing 
actual measurements. All of the analyses calculate figures 
for instruction mixs particularly of NSA instructions», and 
based on the instructior mix and the timing of the various 
Instructionss derive the coefficient "b"™. Coefficient "a" 
is determinec from an actual measurement. | 


The calculations of the two coefficients are based on two 
assumptions: 


1. The mon=-NSA aiainstructions in the GCOS 8 environment 
take an average cf 1.735 microseconds (Ref. 1). 


2. Instructions in the GCOS III environment take an av- 
erage of 1.644 microseconds (Ref. 1,43). 
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3.1.1 Summary 


The following table summarizes the results of the various 
case studies. 


6680 
Performance 
Coefficient 


SD A ECD EO D “ o «< e e 


CASE STUDY 1 
Accommcdation Mode 293 


NSA Instruction use in native mode is 288 
In same proportion as measured in 
SR100C master mode, 


CASE STUDY 2 
CP-6 Secrt Command Executive 2827 


CP-6 Sort Tournament Driver 2928 


CASE STUDY 3 
SR10CC Glotal Data Management 2 86 


CASE STUDY 4 
CP=-6 Measurements 294 
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—6d5661.2 Conclusions 


Although case studies 2 and 3 are based on a static analysis 
rather than actual measurementss the results correlate quite 
closely with the measured results in case studies 1 and 4. 


Two factors are seen te affect performance for the 6680: 
the percentacse of NSA instructions executed and the percent- 
age of CLIMB instructicns executed. Most of the NSA in- 
structions are slightly slower than non-NSA instructions. 
howevers the CLIMB 1s over ten times slower, 


% CLIMB's %Z Non NSA Case Study Coefficient “b"™ 


A ED AD AAD ANG NS EAE AD NS —~SED ED  -A + OR A ED «Ah AND ND AD AD A ARE ED RD A ON DD ND DY “NE IEE <ED -SETWEND - N —CUND TED “UND EN ~~ 


.03 84.48 4 2935 
204 87.37 é 2945 
05 87.3 4 2945 
21 98418 1 293° 
228 90.33 2; .928 
sé 89.0 4 - 88 
293, 91.19 | 3 ~86 
1.36 90.36 2 2827 


The following table provides an estimate of the 6680 perfor- 
mance values for the GCOS 8 environment. The coefficient 
"5b" ds an average of the first three case studies. The CP=—6 
measurements are not ircluded due to the unrealistically 
small percentage of CLIME'’s. 


GCOS III GCOS 8 Gcos 8 
Accommodation Native 


TE SAD OD TD AOD NN AER “CREED ND COND ANN EE . TAD D GD ONES - D - A -E SAAD  -D -~ D 


6680 X 293X 2 87X 


> - ND E ED AED “AND OND EE TAO AAA OD AY CD PU A OT ORE SO, A OU ED ~<A ED UD IS -<O +-D + NP SD 
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3.145 Case Study 1 


The table below Summarizes the results from measurements of 
GCOS 8 Accommodation Mode (Ref. 1), 


Instructicn % of Total 6680 Weight 6680 Weight 
Type Instructions Factor Value 
LDP 1.2 2.0 2240 
LDD 0.18 lay 0.342 
CLIMB ore 20.5 2205 
EPPR 0.06 0.3 0.0178 
Other NSA 0.28 2a 0.56 
Non NSA . 98.18 5 rn io pe 170.34 
Weighted Totals 176.868 


Coefficient: b = 1€4.4 / 176.868 = 0.930 


In accommodation modes the slave instructions are bdased on a 
single segment environments while the master mode instruc~ 
tions are based on a multisegment environment. One can pre-~ 
dict the performance of the multisegment environment by con- 
sidering only the mix of master mode instructions. This is 
presented in the table below. 
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Instruction 4 of Total 6680 Weight 6680 Weight 


Type Instructions | Factor Value 
LDP es 2.20 15.60 
LOO Ase 1.9 2.28 
CLIMS 0.6 20.5 12.3 
EPPR 0.4 Cas 0.12 
Other NSA » eo emg 2.0 
Non NSA 89.0 eto 154.415 

Weighted Totals ~—6©186.715 


Coefficient: b = 164.4 / 186.715 = 0.88 


3.1.4 Case Study 2 


A static analysis of two Sort/Merge modules implemented in 
PL~6 for CP-6€ is shown below. Since these modules do access 
multiple segments and are written in PL-6s they should pro- 
vide a good indication cf overall multisegment environment 
performance. 


The first table shows the results for the Sort Command Exec- 


utives while the seconc table snows the results for the 
Tournament Driver. 
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Command Executive 


Instruction % of Total 6680 Weight 6680 Weight 
Type Instructions Factor Value 
LDP 6.2.01 2.0 A202 
LDD 0.0 1.9 0.0 
CLIMB 1.36 20.5 27.88 
EPPR 1.36 0.3 0.408 
Other NSA 0.91 2.0 1.82 
Non NSA 90.36 Ve155 156.77 
Weighted Totals 198.898 


Coefficient: b = 164.4 / 198.898 = 0.827 


Teucnament Driver 


Instructicn 4 of Total 6680 Weight 6680 Weight 
Type Instructions Factor Value 
LDP 7429 2.0 14.58. 
LDO 03:0 1.9 G40 
CLIMB 0.28 20.5 5274 
EPPR 0.28 Oe 0.08 
Other NSA 1.282 220 3.64 
Non NSA 90.33 1.7395 156.72 
Weighted Totals Vi (eld 


Coefficient: b = 164.4 / 177.12 = 0.928 
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3.1.5 Case Study. 3 
A static analysis of the Global Data Management module of 
ITP yielded the results shown in the table below. Though 
coded in GMAFs this module was chosen for the following rea~ 
sons: 
- it is highly structured 


- it jis reasonably large (5K) 


- it deals with many segments som that register 
optimization is timited 


~ it is reasonably linear so that the assumption that a 
uniform execution takes place should be a good one — 


Instructicn % of Total 6680 Weight 6680 Weight 
Type Instructions Factor Value 
LDP | 17S 2.0 5492 
LDD 1.64 1.9 | 3.12 
CLIMB | 0.93 | 20.5 19,06 © 
EPPR 2.3 | 0.3 | 0.69 
Other NSA 2.216 240 | 4.232 
Non NSA P1419 Te750 159.45 
Weighted Totals 190.16 


Coefficient: b = 164.4 / 190.16 = 0.86 


This module coes perhaps do more register optimization than 
a PL-6 generated module might. The relatively high percent- 
age of EPPR's 3s due to moving the contents of one ODR to 
another. In a PL=-6 module this would probably generate a 
LDP rather than an EPPR. If onemhalf the EPPR's are changed 
to LDOP'ss then the following figures are generated. 
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Instructicn % of Total 6680 Weight 6680 Weight 


Type Instructions Factor Value 
LOP 2491 260 5.82 
Lob 1.64 io 3.12 
CLIMB 0.93 20.5 19.06 
EPPR g fee io G45 0.345 
Other NSA 2216 240 4.32 
Non NSA 91.19 1.2735 159.450 

Weighted Totals Vee: V5 


Coefficient: b = 164.4 / 192.115 = Q. 86 


It is interesting to note that the number of LDP's executed 
is of Little consequence on the 6680 since the instruction 
time is not significantly greater than for other instruc 
tions. 


3.1.6 Case Study 4 


The tables below summarize the results of three CP-6 mea- 
surements. The average cf the three measurements results in 
b=.942, See reference 4 for more information, 


These measurements are rot indicative of GCOS 8 timing due 
to the very small ratic of CLIMB's to total instructions 
executeds but are incluced for a comparison of typical in- 
structicn mixes. 
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Measurement 1 


Instruction % of Total 6680 Weight 6680 Weight 


Tyce Instructions Factor Value 


LOP (05 220 14.5 
LDD 0.0 1.9 0.0 
CLIMB —6 004 20.5 0.82 
EPPR 2.17 0.3 | 0.651 
Other NSA 3417 2.0 6.434 
Non NSA : 87.37 1.735 151.587 


Weighted Totals 173.898 


Coefficients b = 164.4 / 173.898 = 0.945 


Measurement. 2 


Instructicn % of Total 6680 Weight §680 Weight 
Type | Instructions Factor - Value 


LDP 7.15 2.0 1253 
Loo 0.0 1.9 0.0 
CLIMB 0.65 20.5 1.025 
EPPR 2.25 ss 0.675 
Other NSA S325, . 220 6.5 
Non NSA a (87.3 | 1.735 151.2466 


Weighted Totals | 1734966 


Coefficient: b = 1€4.4 / 173.966 = 0.945 
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Measurement. 3 


Instructicn % of Total 6680 Weight 6680 Weight 
Type Instructions Factor Value 
LDP 12.31 220 24.62 
LDD 0.0 ie 0.0 
CLIMB 0.03 20.5 0.615 
EPPR tad? OS 0.411 
Other NSA 1.81 2 a0 3.62 
Non NSA 84.48 1.735 146.573 
Weighted Totals 175.839 
Coefficient: b = 164.4 / 175.839 = 0.935 


3.2 Qbiect Code Analysis 


This section compares projected multi=segment code genera- 
tion of COBOL and FORTRAN in GCOS 8 with the actual code 
generated in GCOS-III. This discussion describes parameters 
of the comparisons highlights results from the comparison, 
and concludes with recommended future directions. 


Detailed numbers are net presented. 


3.2.1 Source Program Descrintions 


FORTRAN =——~ This program is a matrix inversion from a scien- 
tific benchmark. Of significant interest was the analysis of 
code production within the program's innermost loop. This 
critical code section was determined to be executed 100 mil- 
Lion times. 


COBOL-74 -~ This programs obtained from a benchmark support 
demonstration programs heavily uses COBOL“-74 string manipu- 


Lation verbs ~~ INSPECT, STRING, UNSTRING and the PERFORM 
verb. 


3.22.2 Iyges af Cogoarison 


FORTRAN == The program was compiled with FORTRAN-Y. It then 
represented the GCOS-III environment. The innerloop code was 
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examined and changed according to multi-segment environment 
requirements. This versicn then represented the GCOS 8 envi- 
ronment. | 

Those two versions were then compared in two waySe Firsts 
the GCOS—-III version was compared with the GCOS 8 version 
assuming the hardware was constant (6680). Seconds the envi- 


ronment was held constart (multi-segments, GCOS 8) and the 
hardware varied (6680 vs. ADP). 


COBOL=74 -- This program was handled in the same manner as 
the FORTRAN program -~ an existing CBL74 generated code 
Listing was compared with a hand-coded GCOS 8 version. 

3.2.3 Information Obtained 

3.2.5.1 Dynamic 
FORTRAN == The innermost loop instruction count was examined 
in terms of number of irstructionss and execution time ac- 
crual per loop trip. Execution time was adjusted for ADP 
pipeline breaks and cache misses. 
COBOL~74 <-= Since this routine contained neither iterated 
code or conditionally executed code, a static analysis was 
sufficient. 

Se@aSae Static 
For all routines the following information was recorded: 

* routine name 


* number Lines of source 


* size of produced procedure for each environment being 
comcared 


* number LOPnN produced for each environment 
* percent LDPn for each environment 


x the average number of words of procedure code generated 
for each procedure statement for each environment. 


3.2.4 Results 
* The COBOL~74 sample had a relatively low level of LDP's 


(14). A COB0L~74 sample with more parameter passing 
would generate more LDP instructions. 
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* The COBCL-74 sample has a potential problem regarding 
excessive ADP pipeline breakage during execution of 
Subrcutire and Library call Linkage. 


* The COBOL~“74 multi-segment sample also has an excessive 
ADP pipeline breakace problem for PERFORM code genera- 
tion. This problem results when exiting a perform block, 
12@e.2 "TRA to a TRA", 


x COBOL-74 generated code for the multi-segment environ- 
ment CADP) snould execute above the ADP 6X baseline. 


x Degradation from tte GCOS-III performance baseline 
should be Less thar 104 for COBOL~74 generated code, 
Since COB80L-74 has ro “dynamic” pointers except passed 
parameters, it is essential to continue glotal register 

assignments for parameter addresses and further to ex- 
tend COBOL~74 to subject base pointers (to working stor- 
ages process areas etc.) to the same register management 
as parameter addresses. 7 


x The FORTRAN sample also had a relatively low number of 
LOPS (2.34). Agains this was partially due to the nature 
of the Language (no cynamic data segments)s however much 
credit tec reducing this figure must go the the FORTRAN-Y 
optimizers as there was parameter passing of signicance 
(4 cer subroutine call). The LDPs for the parameter ad- 
dress loading totaled 400 (4 parameters * 100 cails to 
the matrix inversior routine). However, references to 
these parameter adcress values totaled within the 
innerloog one millicn. Thuss the ratio of loads to use 
was quite lows as well as being wetl sesdarated. 


x FORTRAN cenerated coce for the multi-segment environment 
CADP) shculd have no problem meeting the ADP 6X baseline 
perfcormarce goal. Ir facts after accounting for cache 
misses and pipeline breaks, this inner loop code 
Improved in excess of a 10X factor. 


* There should be minimal degradation when comparing 
GCOS"-III environment code productions with GCOS 8 
multi-segment environment code productions. The 
innerloog code in particular should not degrade at ail 
Since there are no calls and no LOPS are within it. The 
degradations if anys would result from the new calling 
sequence and the glotal pointer register loads upon each 
entry to the matrix inversion. Howevers as previously 
étated,s those events only occur 100 times. 
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3.2.5 Conclusions 


1. 


From the small number of programs examined it would ap- 


pear that both FORTRAN~-Y and COBOL will meet the per- 
formance goals for the code generated by the compilers. 
More work needs to be done to quantify performance in 
this area as well as in the linkage to the I/0 support 


routiness which was not analyzed. Suggestions for this 


are included in the recommendations, 


Global cptimizing cecmpilers will have a significant ef- 
fect on performance. This is true on the 6680 where an 


optimizer would recuce the number of Load Pointer in- 


Structicns generatec and executed. [t will be even more 
Significant on the ADP where an optimizer would take 
advantage of the pigeline as well as reduce the number 
of Load Pointer instructions. 


3.2.6 Recommerdations 


1. 


Cs 


Plans should be put in place to add optimizers to all 
language translators which do not have them, 


Possibilities of a binder changing/adding/celeting in- 
structicns in addition to relocating addresses should 
be studied. The possibilities include adjusting of ad-~ 
dress fields in conjunction with the removal of address 
register manipulation and recognizing references to 
bound segments and changing references as a result. The 
extreme to which this can be utilized is to bind pro-~ 
grams and data into a single segment. : 


Improve the code gererator in the COBOL~74 compiler to 
improve the instructions generated for both PERFORM and 


CALL. 


Perform studies on €COS-III by inserting pulse instruc- 
tions into the call and entry operators to cetermine as 
much of the information on performance factors as pos- 
Sible and compare those with the hand calculated num- 
bers for the recommended model. 
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4.0 Migration 


xxx To be supplied *x** 
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SECTION 5 


DETAILED SPECIFICATIONS 


1.0 Control Structures 


To be supplied. 
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e.0 Interface Conventions 


To be supplied. 
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APPENDIX A 


ADDRESS REPRESENTATION 


1.0 Introduction 


The representation of address values is the central problem 
in the design of the micro-structure for the multi-segmented 
run-time environment. The use of address values 1s wide- 
spread and interacts strengty with the overall system goals. 


Address values are required in the implementation and con- 
trol of: 


Exception Processing 

Memory Management and Software Stacks 
Arguments and Parameter Referencing 
Locate mode input~output 

List structure processing 

Connection to run-time support 


In high order languagess these facilities show up as dis- 
tinct language constructs fors 


Pointers and SBased Storage 
Entries and Labels | 
Alternate returns ard Exception conditions 


Both the facilities and their high order Language constructs 
appear in Honeywell and customer software. Their wide usage 
1s reflected in the larce number of system goals that are 
related to the choice of address value: 


Jobo performance and throughput 

Uniform micro~structure 

User visible address vailues 

Autcmatic space allccation and recursion 
Exception processing 

Large procedures and data spaces 

Support of virtual environments 

Support of shared elements 

Provide program and data integrity 


ADDRESS REPRESENTATION Anm1 March 31, 1980 - 15:20 


Use current hardware 
Minimize ITP conversion 


In the cesign process» these several aspects of address val~ 
ues were reduced into the following set of design criteria: 


* The address value must be storable in user data space, 
The address value representation must be a legal slave 
space data format. 


* The adcress value representation must allow uniform 
reference to domain~external parameters and 
domain-~local data. 


x The substantive address value must retain its identity 
throughcut being Loaded into and stored from an Operand 
Descriptor Register CODR). 


* The address value representation must support bit level 
addressability for cperands.. 


* It is cesirable that the address value representation 
use hardware with relatively high performance, 


x Tt 4s desirable that the address value representation 
support segment level content integrity. 


* It is cesirable that the address value representation 
support an addressatility greater than 256K words. 


* It is cesirable that the address value representation 
Surprcort domain structures containing more than 1024 
segment S. 


* It is desirable that the address value be valid across 
domains .« 


The following sections ciscuss the alternate address value 
representations investigated. . 
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22.0 NSA Pointer 


The NSA pointer 1s a hardware single word data format 
containing an address field and a segment identifier. The 
word has the following fcrmats: 


0 2 2 3 
Q 3 4 >) 


| address field | segid | 


The address fields, bits C-234 has the same format as an ad- 
dress register and gives a words bytes, and bit offset into 
the associated segment. The segids bits 24-35, identifies 
the descriptor segment énd entry value for the descriptor 
framing the associated segment. The segid may reference 
only the linkage descriptor segments the argument descriptor 
segments or the parameter descriptor segment. The size of 
the segid field allows a maximum of 1024 entries in each of 
the three descriptor segments. 


There are several drawbacks to the use of the NSA pointer as 
the address value representation: 


1. The hardware instruction for loading a pointer (LDP) is 
not one of the faster NSA instructions. The instruction 
is inherently slows since it includes a second memory 
access to acquire the NSA descriptor referenced by the 
segid value. 


2. The address field cf 24 bits Limits the useful offset 
value to a segment cf 256K words. 


3. The NSA pointer is effectively Limited to a domain of 
1024 segments. A dcmain is defined by the contents of 
the Linkage descriptor segment. The segid value makes 
direct reference to the linkage segment and is Limited 
to 1024 entries. 


4. The NSA pointer value is not valid across domains. 
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3.0 NSA_Descriotor and Address Register Value 


The NSA descriptor is @ hardware double-word data format 
identifying the Location and extent of a segment. Since both 
location anc extent are in terms of bytess the NSA 
descriptcr must be accomcanied by an address register value 
to give the bit address cf the operand. This three word ad= 
dress value representaticn would have the format: 


Q 1 2 3 

0 9 0 5 
[eae eee eee eee | eee eeeeee oo aes] 

0 | bounds | | controls | 
| ean icin “sinc li <select | oi te ces in “up cis <tc sais ln ns i ees <a | 

1 4 base | 
| em a ae ne ee | ee eee ee = | 

2 | bit address | unused | 
| aan oe en a nnn | eo oe = = | 

0 22 3 

Q 7 3 4 5 


The bounds fields, bits 0-19 of word O» contains the maximum 
valid byte address within the segment. The control field, 
bits 20-35 cf word 0,» identifies the working space within 
which the segment resides and contains access control infor- 
mation. The base fields word 1, locates the byte offset of 
the segment within the werking space identified by the con- 
trol field. The bit address, bits 0-23 of word 2+ has the 
same format as an address register and gives the words byte 
and bit cffset of the cperand within the segment. 


Using a NSA cescriptor plus an address register value as an 


address value representation has the disadvantage that such 
a construct cannot usefully be stored into user data space. 
Although the address register value and descriptor content 
can be stored into operand spacer the descriptor cannot be 
loaded into a descriptor register from operand space. Sepa~ 
ration of the address register vaiue in operand space from 
the descriptor ina special descriptor segment raises insur- 
mountable problems in syrchronizing the two spaces and pass- 
Ing address values between procedures witnin a domain. 
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4.0 Segment Table Index 


When represented as a bit address and an offset (index) into 
some descriprtor segments the address value representation 
would require a two word construct: 


0 2 2 3 

Q 3 4 2 

| a <a“ enh ian semi gs. ‘ima sa th ial =n <n ata | ATT DO OED AG OD a eae te a j 

QO } bit address | unused l 
| enn ee ee tn ae cee eee | ee | ee ee ee me om | 

1 | segment index | unused | 
| <0 Eb ED ED <0 ~~ ee -< <ae e- e | sss ip tm ei scab “cs Si: <i it | 

0 1 1 3 

0 7 8 5 


The bit address fields, bits O-23 of word O- has the same 
formst as an address register and gives the words bytes, and 
bit offset within the associated segment. The segment in- 
dexs bits 0-17 of word 1s contains a value that identifies 
the prorer descriptor within an associated descriptor seg- 
ment. The descriptor segment would have to be located by a 
descriptor at some cancrical position in the linkage seg- 
ment. To maintain efficiencys at Least one IDR would have to 
be dedicated to framing this descriptor segment. 


There are at Least three drawbacks to the use of this format 
for the address value rerpresentation: 


1. The value of the address value cannot be maintained 
across the loading cf an ODOR. The associated descriptor 
can be placed into an ODOR and the bit address value can 
be placed in the matching address register. There is 
no places, howevers in which to remember the segment in- 
dex value. There is no ways therefore, in which the 
address value can be reconstituted in data space. 


2. This format is not especially efficients, recuiring sev- 
eral instructions te load the ODR and address register. 


3. This representation is not valid across domains. 
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92-0 Super Pointer 


The super pcinter representation of an address vatue is 
predicated on all of the data segments in a domains regard- 
less of access controlss being collected into a single super 
segment. The super pointer locates data within: this super 
Segment. The super pointer is envisioned as a two word con= 


struct: 
0 2 2 3 
0 7 3.4 5 
Ss ee ee 
0 J bit address ] unused | 
| enn ae a ae me ne ee eee ene | re ee ene ene ae | 
1 | extended base | | 


The bit address fields bits O-23 of word O» has the same 
format as an address register and gives the words bytes and 
bit offset from the base value within the associated super 
segment. The extended tase fields» word 14 gives the byte 
offset of a datum within the associated super segment. The 
Super segment itself woild have to be located by a super 
descriptcr at some cancnical position within the Linkage 
segment. Teo maintain efficiency, at least one ODR would 
have to be dedicated to framing the super segment. 


There are several drawbacks in using a super pointer as the 
address value representation: 


1. Address values represented as super pointers stored in 
user data space can point only into the super segment. 
Parameters passed into a domain are not in the super 
segment. Therefores parameter address values cannot be 
represented via super pointers. 


Moving parameter values into the invoked domain and 
back to the invoking domain is inefficient, 


Creating selfe-describing super pointers is inefficient 
in that each pointer would have to be tested for type 
before being utilized. 


2. The collection of all data segments of a domain into a 

| Single super segmert vitiates any attempt to control 
the access to particular segments or classes of data, 
All of the content cf the super segment would have the 
Same access permissions as the most pudlic catum in the 
Super segment. 


3. The super pointer is not valid across domains. 


ADDRESS REPRESENTATION | A-6 March 314 1980 = 15:20 


6.0 Evaluation Summary 
The following table summarizes the attributes of each possi-~ 
ble address value representation against the stated design 
criteria. 


CRITERION RANK NSA DESC. TABLE SUPER 


PTR. ADDR. INDEX PTR, 
Storable in data space must Y N Y Y 
Uniform parameter referercing must Y Y oy N 
Retain identity through CDR must Y Y N = | 
Bit level adcressability must Y Y Y Y 
Relatively high performarce 1 N Y N Y 
Support segment integrity | 1 y Y Y N 
Addressability greater than 256K 2 N Y Y Y 
Domains exceeding 1024 segments 2 N Y Y Y 
Valid across domains 3 N Y N N 


Only one alternatives the NSA pointers supports all of the 
absolute requirements. 
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APPENDIX 8 


DESIGN SOURCES 


The following sections describe alternative program environ- 
ment definitions considered as input to the GCOS 8 design 
process. 
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1.0 Multics Program Environment 
1.1 Qbiectives of Multics Runtime Environment 


Ease of pregram development 
Considered major and increasing factor in computer expense 
System developers as well as end users 

Large address space | 
Minimum pre-specification 
High Level Language support 

Efficient execution 
Minimize copying 
Minimize main storage requirement 

Protection 
User from himsel f 
User from other users 
System from user 
Accicent or malice 

Resource administratior and control 
Centralizable or delegatable 
Automatic 
Flexible 

Adaptability 
To different needs of different users 
To varying scale configurations 
To future requirements 
To future technology 

New devices 
Declining cost of storage 
New pregramming Languages and techniques 


1.2 Eeatures cf Multics Runtigae Environment 


Process is fundamental structure 
Addressing mechanism 
Memory size Limits 
25€K werds per segment 
4094 segments per ecrocess 
Segmentation 
Hardware supports use of segment number and offset 
Pointer registers 
ITS aindirect wore pair 
Implicit use of Frocedure Segment Register 
Uses of segments 
Procedure segments 
Single compilations directly executable 
Bound segments same format as compiler output 
Pure procedure 
Data segments 
Process private 
Shared 
Supervisor procecure and data 
Paging 


DESIGN SCURCES B-2 “March 314 1980 - 15:20 


Invisitle to user 

ALL instructions and modifiers work across page fault 
Segments don't share pages 
Page mapped 1:1 with disk records memory encaches disk 
segments can grow 

Zero pages in secment allocated when stored into 
Uses of paging 

Efficient buffer allocation 

Configuration incependence of user programs 


Security and integrity 
Access centrol per-segments per-user 
Derived from information in file system 
Upcated immediately if information changes 
Access ccntrol dimensions 
Intraprocess access control: rings 
Rings O-7, O most privileged (central) 
Brackets for writes reads executes, call 
Hardware validation of ring number in pointer 
Uses 
Protection of supervisor from user 
Running a program in an isolated environment 
Previding controlled use of data or program 
Per=user access cortrol: Access Control List 
Modes Reads Executes Write 
Enforced by hardware on every reference 
Uses 
Read sharing: use of common data and program 
Memory and channel efficiency 
Coordination of user activity (library) 
Write sharing 
Process synchronization 
Nondiscretionary access control: Access Isolation Mechanism 
Level and category,s, like military security ; 
Uses 7 
Prevention of accidental disclosure of information 
Defaults make access control transparent for common case 


Generated code 
Stack segment (per<-ring) for program temporary storage 
Stack header has environment definition pointers 
Hardware knows stack segment number and register convention 
Does not know any fixed offsets in stack 
Recursive code stardard 
Threaded code with oferator segment references 
Operator segment shared by multiple processes, all rings 
Operator segment lLeccated by language convention at entry 
Stancard object segment format 
Text Cinstructions.and constants) 
Definitions (inward reference) 
Entrypoint 
Argument descriptors for each entrysoint 
Symbol Coptional) 
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Static template Coptional) 
Break map (for debuggers) (optional) 
Object map 
Linkage section per ring 
Contains ITS pointers or fault pairs 
Supplies segment number for external reference 
Static storage area fer ring 
Allocated in the same place as linkage 
Stancard call operater 
Used even by assemctly language programs, via macro 
Stancard argument list 
Header | 
Argument pointers 
Argument descriptors 
Standard data representation 
ASCII character set 
Machine=supported cata types 
Array and string representation 
Packing and alignment 
Pointers 
Implemented as ITS pairs can use for indirection 
Packed pointers 
Ring number in pcinter in storage 


Supervisor 
Name management 
Segments searched for by symbolic name 
Assigned segment number and made known 
Subsequent searches for same object very efficient 
Per=ring search rules control search for object 
Referencing directory rule helps subsystem packaging 
System command irternals available to user 
Site may modify cefault search rules 
Linkage and name space not reset implicitly 
No job step or ccmmand concept 
Run unitss explicit termination optional 
Interprogram linkage 
Dynamic Linking stendard 
Binding optional 
PrelLinking optional 
Unlink ing of dynamic Link on demand 
Run units | 
Supervisecr calt and return 
Same mechanism as any other call 
Inner ring programs take some care not to be subdverted 
Excegtion handling 
Error indication 
Symbclic error ccdes onlys numeric values sealed 
Convention is to use final argument of subroutine 
Standard I/0 stream for error messages 
Query handling 
Signal mechanism 
Condition handlers 
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Clearup handlers 
Any _other handlers 
Cross-ring signalling 
Static condition handters 
Hardware faults handled as signals 
QUIT handled as signal 
Default environment action 
New command Level 
Starts» release 

Process terminatior 

Epilogue handlers 
Replace parts of environment 

Subset 

Extend 

Test new version 

Uniform execution recardless of input stream 

Stream I/0 system 

Resource Control Package 
Symbolic resource names 

User may create outer module 

User may generate (CCWs for 1/0 
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2.0 CP-6 Program Environment 
2.1 Goals 


The goals of CP-6 are tc provide an attractive upgrade al- 
ternative to Sigma series hardware users by offering a sys- 
tem personality very similar to CP-V. Conversion of data 
files in format and from EBCDIC to ASCII was assumed neces~ 
sary but all file system and file access method 
functionality of CP-V was copied as closely as pcecssible,. 


Development of the system was to be based on using a higher 
order language for most cf the implementation. Both external 
(command Language) and irternal (calling sequence) uniformi-~ 
ty were given early attertion and high priority. 


Compatibility with GCOS was explicitly of secondary impor- 
tance. 


2.2 General Characteristics 


CP-6 uses the same NSA hardware as GCOS 8 but in a much more 
Limited way. Although stcrage managemment takes advantage of 
the page tabless dynamic paging 18 not supported. The do- 
main structure of user programs is fixed and the user ad-~ 
dress space is Limited tc a total of 398K words, | 


Approximately 90% of system software is written in PL-6, 
Uniform interface conventions are strongly enforced, 


The system is seperated into four domains and each user has 
a single domain. The system domains ares: 


Monitor 

Command Processor 
Interactive Debugger 
Alternate Shared Library 


2.3 Process Structure 


Each user process is assigned a Working Space of fixed 
Structure, 


o A fixed page table space allocation Limits each WS to 


o The user program can access at most 398K of the WS. 
o There is one domain having a fixed segment structure, 
Oo Segments addressatle by the user process are; 


~ Instruction Segments 256K maximum size. 
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~- Control Segments 14K maximum and Read-Only. 


- Data Segmertss at most 8 segments totalling 
128K. 
o The WS page table is used for memory control. 
- Certain cortions are pre~assigned for 
functions. 
- Process and/or constant data sharing 1s 


achieved by mapping the same physical page into 
two or more WS page tables. (32K of user in- 
struction segment is normally reserved for a 
"lLibrary”™ of shared pure procedure.) 

- The user pregram may request dynamic allocation 
of pages in the page table. 

- Overlay usage in the Instruction Segment is 
supported. 


2-4 Program Structure 


Compiler output is not directly executable but must be 
Linked with its supportirg subroutines into a run unit. 


Large programs must be overlay structured in a conscious 
WAY» 


Intra-domain procedure calls are implemented using TSX in- 
structions. 


The user domain may CLINB to the Alternate Shared Library 
and reaches the Monitor ty PMME, 


The user process may directly manipulate pages: 
- allocate and free data segment space in words, 
~ allocate and free real Instruction Segment pages oth- 
er than those allccated via the linking process, 
- Allocate and free virtual Instruction Segment pages 
other than those allocated via the Linking process. 


Subroutines may be sharec only by being page mapfed into the 
top 32K cf the Instructicn Segment. 


User procedures may be shared via special post-linking 
processing tc identify them as sharable elements. 


Hardware pointers and vectors are usable via both assembly 
language and PL-6. | 


Compiler outfut segregates data and procedure. Pure proce~ 
dure is created by PL=-6 to allow sharing. 
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2.5 Exception Processing 


The standard calling sequence provides for an alternate re- 
turn point. 


A one-way inter-procedure exception path is supported by the 
PL=~6 REMEMBER/UNWIND feature. 


Process level exceptions (ON conditions) are supported via 


ASYNCHRONOUS procedures and the MSXCON (exit control) facil- 
ity of the ocerating system. 


2.56 System Personality 


A single JCL provides fcr both batch and interactive usage 
modeS.e | 


The same system interface mechanism 1s available to programs 
in batch and interactive execution modes. 


The same 1/0 mechanism werks for both batch and interactive 
programs. The inteactive state may be determined from file 
attributes. | 


System search rules are the same for JCL and programmatic 
procedure invocation. 


System modules are dynamically replaceable without system 
interruption. 
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3.0 GCOS. 8 SR_1000 Program Environment 
3.1 Beoief_History 


The native environment present in SR 1000 is partially 
inherited from ACOS V1.1 which was based on a-Toshiba-HIS 
joint design effort goirg back to 1975 and 1976. It goes 
beyond that base in many ways including checkout of the mul- 
tiple Shared Run Unit Litrary capability and the addition of 
a limited capability Dynamic Linker. 


3.2 Geals 


The goals of the release which apply to the native environ- 
ment includes: 


o Overcome Limitations of GCOS-III 
-~ Slave memory size 
~- Files per activity Cincreased PAT space) 
~ Program number timit 
—~ SSA module fragmentation 
- Memcry fragmentation (compaction overhead) 


o Utilize NSA hardware features 
- Optimize real memory utilization 
- Improve integrity and security 


o Support the Integrated Transaction Processing system 


3.3 General Characteristics 


The unicue address space of a program is in a private Work- 
Ing Space “viewed” through WSR 7. This process-tocal Work= 
ing Space is divided into control information storage (the 
process structure) and program storage. The first 64K vir- 
tual. addresses are reserved for control information and 
descriptor storage. All used pages in this area must be 
memory resident when the process 1s not swapped out. 


Dynamic paging of both program and shared address spaces is 
supported by ruling out tunsupportable instruction sequences, 
Explicit overlay management is not supported by the system 
in native mode, 


Program construction facilities treat each compile unit as a 
domain. Thus all runtime services are invoked by a CLIMB in- 
struction. 


Segmentation is assumed in program construction and iis al-~ 


ways based on standard descriptors. This means that the 
largest segment size is 256K words. 
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Operating system Services are reached either by a CLIMB or a 
PMME ‘instruction. The interfaces are not consistent in style 
and some have undesirable features such as passing codes in 
registers. 


3.4 Sharing Mechanisms 


Addressability to Sharec Working Spaces is available to a 
Native made program via WSRs 2-6. Content of these Shared 
Working Spaces may be loaded by an unrealesed utility to 
Working Spaces having fixed relationshiass to the WSRs. 
These relationshipss the status of the contentss and other 
information is recorded ina hard-core table, 


An unreleased utility frovides optional static Linking to. 
Shared domains but Run Units so linked are vulnerable to 
changes in the content of Shared Working Spaces to which 
they are linked. Compatibility of a Run Unit with the 
Shared Working Spaces available at the time of its execution 
is checked tc prevent a mis~match. | 


Alternativelys dynamically assigned Working Spaces may be 
loaded by a loader program which is part of the 
developmental scaffolding used by ITP. The Shared Working 
Spaces in this method are controlled by a "sleeping" process 
which holds the Working Spaces backing stores etc. 


A primitive Dynamic Linker supports linking to ITP shared 
software. 


3.5 Process Structure 


User prceogram (process local) virtual address space may be at 
Least 1.6 million words. 


More than 25C files may te assigned to an activity. 
Construction of both user and shared programs is completely 


flexible (within hardware constraints) in the use of multi- 
ple segments and multiple domains. 
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4.0 GCOS-]Vse June 1979 Progran Environment 
4.1 Brief History 


This environment definition was developed primarily within 
the Language and Database organization in 1978 -and 1979 to 
provide a base for compiler planning and particularly to es- 
tablish a target environment for the development of PL-6 for 
GCOS 8. It is a slight extension of the SR 1000 environment 
In that rew approaches are taken to the construction of pro- 
grams which free the system designer to construct domains 
from multiple compile units. 


Certain conventions worked out during development of this 
specification became part of SR 1000. In particulars, domain 
structure, null descriptcrs, null pointer and revised excep- 
tion processing conventicns were adopted, 


4.2 Goals 


Definition of the execution environment as seen by a compil- 
er code generator was tke fundamental goal of this effort. 
Support of all general features of higher order language 
systems, efficient inter-module calling sequencess and maxi- 
mum uniformity of conventions were considered of highest 
priority. 


Maximum generality of skarings uniformity» and ease of use 
were alsc taken as tmportant goals. 


4.3 General Characteristics 


The most significant variation from the program construction 
available previously for native mode is the assumption that 
modules generated by a compiler would normally be combined 
with others in a single comain. This choice was made in or- 
der to employ the hardware "pointer™ datum as the "pointer" 
data type of several Language systems. It also led to a 
means af providing intimate run time supporting software 
that could be shared without the use of the CLIMB instruc- 
tion. 


A generalization of dynamic Linking was envisioned in which 
symbolic information in every domain would provide names to 
be matched against directories in each Shared Working Space. 


Dynamic association of Shared Run Unit Libraries with Work- 


ing Spaces and of process with Siared Working Spaces was 
proposed but not fully defined in the specification. 
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5-0 An Environment Modeled_on Multics 


This note describes briefly how to adapt the Multics 
multimseqment runtime environment to the NSA machines in or- 
der to create a GCOS-IV multi-segment runtime environment, 


5.1 Fundamental Mapping 
A Multics segment will be naeeed into an NSA segment. 
Pointer values will be represented by NSA pointers. 
Multics rings will be aprroximated by NSA domains. 


Each domain will have a cescriptor segments segment numbers 
in all demairs of a process will refer to the same segment, 
with possibly different access rights. | 


S22 Detailed Ddescriation 
Se2el Segment Number Assignment and Pointers 


Pointers can be shared between domains only if the segment 
Numbers are assigned identically in both domains. The 
Multics apprcach to this problem involves several rules: 


1. Pointers are never valid after shutdown and reboot. 


22 Pointers are valid across processes only ina special 
case: system=wide assignments of segment numbers to 
Supervisor segments at bootload time. Thuss a pointer 
to a supervisor segment is valid in all processes. 


3. Pointers are freely passed within a processes but it is 
the process's own resposibility to garbage collect 
pointers within a demain (ring). That is» a process can 
construct a pointers hide it somewheres and release the 
segment numbers the pointer is invalid but the system 
does not automatically invalidate the pointer, 


Segment numbers O-N will be reserved for supervisor segments 
in all processes (N set at bootload time). Tnens segment 
numbers N+1 to N+M will be reserved for per-work station 
segmentss where M is variable according to work station and 
determined at process creation time. The rest of the seg- 
ments in the process are assigned segment numbders on a 
first-come, first-served basis. 


This does net preclude two processes sharing a procedure 


segments assigning it different segment numbers in different 
processes. The procedure wills howevers require a Linkage 
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section which 1s impure and per-domain which contains seg- 
ment numbers needed by the executable code to refer to its 


environment and for inward reference, 


5.2.2 Structures Adopted from the Multics Environment - 


Stack 

Stack frame 

Linkage Offset Table 
Combined Linakge Area 
Reference Name Table 
Known Segment Table 
Argument List header 
Argument list 
Argument descriptor 


5e2.5 Procedure call 


One procedure will call another according to the 
scenario. (Suppose A calls 8): 


1. Procedure A prepares an argument list for 
stack frame. 


2. Precedure A obtains a pointer to procedure 8. 
3. Procedure A enters the CALL operator. 


4. The CALL operator saves the return point’ in 
frame and enters precedure 8. 


following 


Bin A's 


A's stack 


5. Precedure 8 performs a standard entry sequence which 


- Builds a stack frame for 8B 


- Establishes addressability for 8's linkage section 


~ Establishes addressability for 8's arguments 


Arguments will be passec as they are in Multicss not via 
CLIMB. The argument list will be a list of NSA pointers to 
argument valuess stored cn the software stack. If CLIMB is 
useds it will not be usec for argument passing. The parame- 


ter stack 1s not used. The only CLIMB opcode will 
operator segment which contains the call operator. 


Seee4 Comaiter Outout 


be In the 


Pointers may be passed between domains. The output of a 


compiler is a file which contains several 


sections: 


executable ccde,y linkage definitions, linkage section tem- 
plates symbol sections ard object map. Output from separate 


compilations can be combined into one segment by a 


“binder.” 
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522.5 Differences from Multics due to NSA 


Compiler output 318 pure procedures threaded code. A process 
may have many domainss but there 1s a Limit of 1024 segments 
per process. (Multics had this limit for many years: most 
processes still operate within it. Administrative action 
can increase the size to 4096 for special processes.) 


Pointers do not carry a ring number. This requires that all 
pointers input to a domain be validated by the callee. Such 
code was once written for 645 Multics: its construction is 
fraught with subtleties and dangers. On the other hands we 
understand the problem. 


Since NSA dces not provide an iITS pointers, all indirect 
addressing must be replaced by explicit register loading. 


The size of a segment is 256K wordss same as in Multicss un- 


less super descriptors are used. These can be used if there 
are some lLimitationss tike only one per process. 


503 What Must be Built 
de301 Sugoervisor. services 
Nane Management | 
Per~domain reference name management. 
Per-process and per-work=station segment number management. 


Per~ring search rules. 
ioteracogran Linkage 


Dynamic Linking 
Unlinking of dynamic Lirk on demand 
Run units 


Supervisor call and return 


Write—arounds to GCOS-8& functions must be provided so that 
the user program can call upon the supervisor by a language 
call instead of via a MME. The supervisor routines must take 
some care not to be subverted if pointer arguments are 
passed. | . 


Exceaotion Handling 


Software convention must be established for 
error code 
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Standard I/0 stream fcr error messages 
Query handling 
Signal mechanism 
Conditicn handlers 
Cleanup handlers 
Any_other handlers 
Cross“-ring signallirg 
Static condition handlers 
Hardware faults hancled as signals 
Default environment action 
QUIT 
Process termination 
Epilogue handlers 


Se dee Language Support 


Standard QOoerators 


The standarc calls pushes, and return ooerators must be 
written. If multiple operator segments are permitted in a 
domain then the conventicns for making the various operator 
segments addressable must be worked out. 


Linker 


The standarc linker must be designed.z« This requires the 
following pieces: | 

Fault handling 

Definition search 

Linkage space assignment 

Linkage temelate Loading 

Process restart 


Binder 


A binder will be requirec for the initial releases, in order 
to conserve segment numbers. 


loterface to language runtime J /0 


Efficiency of the COBOL and FORTRAN I/0 packages will be im- 
portant, and special care must be given to making this funcm~ 
tion efficiert. 
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6.0 Other Inouts 


TBS by GA Mann. 
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APPENDIX C 


DESIGN EVALUATION 


The GCOS Multi~Segment Runtime Environment Committee 
evaluated the alternative design strategies proposed for the 
GCOS 8 MSRTE and chose an approach which was an evolutionary 
development from the current 4VX product. The major reason 
for this choice was the feeling that no other approach could 
be implemented for delivery at the end of 1981. 


Major Aperoaches 
Multics Agoroach 


The Multics approach is a low risk approach to satisfying 
most of the functional design objectives for the runtime en- 
vironment, we know this because Multics satisfies most of 
these objectives and already works. Performance parity with 
GCOS-III is cerobably not possible with this approach, or any 
other acproach considerec: but predicting the performance of 
a Multics~-apcroach envircnment was not pursued in detail. 


The amount of code to be written for the Multics approach is 
known to be larger compiler coce generators for all compil- 
erss binderss Linkerss and supervisor services must be built 
as described above. This amount of code is about the same 
for all proposed implementationss but the additional work 
for the Multics approach would be the rer-implementation of 
4GVX/ITP and other GCOS code to work with the new environ=- 
ment . 


This approach was not given a large amount of consideration. 
Once we cetermined that the complete job was very larges and 
could ncot be reasonably fromised for end of 19814 we turned 
to other schemes. Another reason we did not pursue this ap- 
proach too far was that it used NSA pointers and the LDP 
opcode heavily» and at the time we were in hopes of 
discovering an approach which did not suffer from the per- 
formance problems of this method, 
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1.2 (€P-6_ Aporcach 


We really didn't evaluate this approachs bdecause CP-6 does 
not provide sufficient support for large address spaces. 
The question of how to alter the CP-6 environment to support 
larger address spaces was not investigated. 


123 GCOS. 8 SR 1000 Environment 


Although code generators for all languagess an Amunit merg~ 
ers and a Br-unit binder must be writtens, it is possible that 
some use may be made of the existing loaders, and the dynamic 
Linking and mremory management software used by ITP, 


Compared to the Multics approaches this method might be less 
codes or it might be mores depending on how much old code 
can be adapted to the new circumstances. It is definitely 
more design: many complex features of the RTE would have to 
be inventeds, which coulc be copied from Multics if we took 
the Multics approach. 


If we assume that ITP is going to be kept with minimum 
changes then the desire for a uniform environment will have 
a strong influence on the Shape of the MSRTE. Several 
strategies used by ITP, such as process structures memory 
managements per-~opening domains for every use of a file, 
Cannot be accommodated within many of the possible RTEs. 


Some of the committee menbers expressed the strong desire to 
avoid any caronicalizaticn of domain internals; that is» it 
would be possible to have many different internal structures 
in different domains. This was advanced as an advantage to 
program cevelopers since the effects of an error would not 
propagate. 


124 GCOS-=IV June. 1979 Environ#ent 
This environment was considered to be aminor variant of SR 


1000 and our eventual design adopted features as appropri- 
ate. 
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APPENDIX D 


COMPETITIVE COMPARISON 


TBS 
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MULTI-SEGMENT SHARED RUN-TIME ENVIRONMENT 


oO GOALS & CONSTRAINTS 
oO MACRO-STRUCTURE 
o MICRO-STRUCTURE 


oO PERFORMANCE 


4/18/80 


GOALS 


GOAL 


MIGRATE WITHOUT HOL SOURCE CHANGES 
ACCOMMODATE GCOS-I1I EXECUTABLE FORMATS 
ACCOMMODATE GCOS-III TSS, TDS, & DMIV-TP 
JOB PERFORMANCE AT LEAST 90% OF GCOS-ITI 
THROUGHPUT AT LEAST 90% OF GCOS-III 

USER VISIBLE ADDRESS VALUES 

AUTOMATIC SPACE ALLOCATION AND RECURSION 
EXCEPTION PROCESSING 

DYNAMIC SUBPROGRAM INVOCATION 

SUPPORT LARGE PROCEDURES 

SUPPORT LARGE DATA SPACES 

SUPPORT DISTRIBUTED SYSTEM ARCHITECTURE 
SUPPORT A VIRTUAL ENVIRONMENT 

SUPPORT SHARED ELEMENTS 

PROVIDE PROGRAM AND DATA INTEGRITY 
PROVIDE USER ACCESS CONTROL 

USE CURRENT HARDWARE 


RANK 


MUST 
MUST 
MUST 
MUST 
MUST 
MUST 
MUST 
MUST 
MUST 
MUST 
MUST 
MUST 
MUST 
MUST 
MUST 
MUST 
MUST 


RESPONSE 


YES 
YES 
YES 
TBD 
TBD 
YES 
YES 
TBD 
TBD 
YES 
TBD 
YES 
YES 
YES 
MES 
TES 
YES 
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GOALS (conTINUED) 


GOAL 


UNIFORM MICRO-STRUCTURE ENVIRONMENT 
UNIFORM MACRO-STRUCTURE PERSONALITY 
PROCESS SYNCHRONIZATION 

SUPPORT LARGE NUMBER OF FILES | 
SUPPORT LARGE NUMBER OF TERMINALS 
SUPPORT MULTIPLE VERSIONS OF SAME MODULE 
SUPPORT DYNAMIC SOFTWARE INSTALLATION 
EXTENDIBLE TO FUTURE PRODUCT DIRECTIONS 
SUPPORT ARRAYS LARGER THAN 256K 

PROTECT HONEYWELL PRICED SOFTWARE 
MIGRATE WITHOUT ASSEMBLY SOURCE CHANGES 
TASKING 


RANK 


> FS WN WW BRO BO PO FO PFO LY LH EH 


RESPONSE 


YES 
YES 
YES 
YES 
YES 
YES | 
YES 
YES 
NO 
TBD 
TBD 
TBD 
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CONSTRAINTS 


RELEASE WITH 5V 
MINIMIZE CONVERSTON 
USE CURRENT HARDWARE 


SUPPORT HIGH ORDER LANGUAGE FUNCTIONS 
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SUBCOMMITTEES 


TWO SUBCOMMITTEES WERE FORMED. 


1. MICRO-STRUCTURE SUBCOMMITTEE 
DEFINE THE INTERNAL ENVIRONMENT 
o THE STRUCTURE INTERNAL TO A DOMAIN 
o CALLING SEQUENCES WITHIN & BETWEEN DOMAINS 
o LINKAGE SEGMENT LAYOUT 
MEMBERS : 


DICK WILSON (CHATRMAN), JOHN WERTZ, TOM VAN VLECK, FRANK LITTLE 


2, MACRO-STRUCTURE SUBCOMMITTEE 
DEFINE THE EXTERNAL ENVIRONMENT 


0 


EVERYTHING EXTERNAL TO THE DOMAIN - PROCESS STRUCTURE, OBJECT UNIT 
AND RUN UNIT STRUCTURE, WSQ STRUCTURE, .. . 


o RUN TIME SUPPORT SERVICES - DYNAMIC LINKER, EITC. 

o PROCESS & DOMAIN CREATION MECHANISMS 

o SHARING MECHANISMS JCL, PROCESSORS, . . . 
O HANDLING OF WSR‘S & SEARCH RULES 

MEMBERS : 


CHARLIE COFLIN (CHAIRMAN) GEORGE MANN, AL BEARD 
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EXTERNAL ENVIRONMENT 


1, USAGE OF WORKING SPACE REGISTERS TQ SUPPORT SHARING 


2, TYPES OF SHARING - 


5, CONSTRUCTION OF THE VIRTUAL ENVIRONMENT 


WSR USAGE FOR SHARING 


may e pense: ote aabige ad Aidt anon tae Ac tongrecsinneeceetee ee WSR” 


rr 3.13 oe 
| | liGeme” | 
optiongl 
HARE SYSTEM «= SERARAFERY | SITE DYNAMIC — |WORKSTATION | PROCESS 
shared | Shared 
{ — BREED | SOFTWARE =| _-USER LOCAL | LOCAL /]| 
Ke — Shared | sorruaRe SHARING 


WSRE ~ NSRP ARE COMMON TO ALL PROCESSES 
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TYPES OF SHARING 
1, DOMAIN INSTANCE SHARING 


- LINKAGE IS SHARED 
- ALL SEGMENTS OF DOMAIN ARE SHARED 


| PROCEDURE 
Tota 
| DATA | 


CLIMB 


nine’. 
CLIMB | 


LINKAGE 
SEGMENT 


Li 


TYPES OF SHARING (conTINUED) 


DOMAIN PATTERN SHARING 
- LINKAGE SEGMENT IS NOT SHARED 
- DESCRIBES BOTH SHARED AND UNSHARED SEGMENTS 


SHARED © PROCESS LOCAL 


53, SEGMENT SHARING 
- IF PROCEDURE SEGMENT, THEN: 
oO ALL DATA REFERENCES ARE T0 PARAMETERS OR DYNAMIC DATA 
o PURE PROCEDURE 
- IF DATA SEGMENT, THEN: 
o MUST BE GATED 
PROCESS LOCAL 


PROCESS LOCAL SHARED 


PROCEDURE 
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DEF - A-UNIT 


A FILE OF OBJECT TEXT PRODUCED BY COMPILERS & ASSEMBLERS 


i, 


-  B-UNIT 
A FILE THAT CONTAINS A WORKING SPACE IMAGE 
o ONE OR MORE DOMAINS 
o LINKAGE, PROCEDURE, DATA FOR THOSE DOMAINS 


o SKELETAL PAGE TABLE 


4/18/30 


CONSTRUCTION OF VIRTUAL ENVIRONMENT 


SOURCE 
v 


MERGER 
(OPTIONAL) 


U 
DIRECTIVES : { 


B-UNIT BUILDER 


! 


A-UNIT . . 


B-UNIT OR B-UNIT LIBRARY 


WORKING SPACE 
ASSIGNMENT 


(WSR, WSN, B-UNIT, to ) 


| 


| PROCESS INITIATION | 


PROCESS 
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CONSTRUCTION OF VIRTUAL ENVIRONMENT (CON’T) 


SOURCE 


A-UNIT 


JCL 


> COBOL 
$ PRMFL SOURCE 
$ PRMFL A-UNIT 


FUNCTIONS 


- COMPILES ‘OR ASSEMBLES SOURCE 

- DEFINE INITIAL SEGMENT CONTENTS 
- SUPPLY RELOCATION INFORMATION 

- SUPPLY DEBUG SCHEMA 
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CONSTRUCTION OF VIRTUAL ENVIRONMENT (CON'T) 


A-UNIT] — A-UNITS 


A-UNTT MERGER 


| 


A-UNIT 


JEL 


$ A-MERGE 
$ PRMFL  A-UNIT, 


$ PRMFL  A-UNIT, 


$ PRMFL OUTPUT A-UNIT 


FUNCT IONS 
- COMBINES SEGMENTS 


- PERFORMS RELOCATION 
- ADJUSTS SYMBOLIC SEGMENT REFERENCES 
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CONSTRUCTION OF VIRTUAL ENVIRONMENT (CON’T) 


DIRECTIVES A-UNIT; = A-UNIT> 


B-UNIT 


V/ 
B-UNIT BUILDER 


JCL 


$ B-BUILD 
$ PRMFL A-UNIT, 


$ PRMFL A-UNIT» 


$ DATA 
DIRECTIVES 
$ ENDCOPY 


FUNCTIONS 


- CREATES DOMAINS 


- ASSIGNS VIRTUAL SPACE 

- RESOLVES REFERENCES 

- CREATES DIRECTORY OF DOMAINS AND GLOBAL SEGMENTS 

- ADD, DELETE, OR REPLACE A-UNITS IN AN EXISTING B-UNIT 
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CONSTRUCTION OF VIRTUAL ENVIRONMENT (CON’T) 


B-UNIT OR  B-UNIT LIBRARY 


WORKING SPACE ASSIGNMENT 


JCL 


$ RUN 
$ PRMFL B-UNIT 
$ SHRNM SHARE LEVEL, B-UNIT LIBRARY 


FUNCTIONS 
- ASSIGNS WSR AND WSN 


- CREATES A BACKING STORE FILE 


~ CREATES A DIRECTORY OF DOMAIN AND SEGMENT NAMES FOR 
ALL B-UNITS IN WS 
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CONSTRUCTION OF VIRTUAL ENVIRONMENT (CON’T) 


ASSIGNED WORKING SPACE 


PROCESS INITIATION 


sees 


JCL 


$ RUN 
$ PRMFL  B-UNIT 


FUNCTIONS 
- ASSIGNS KPX 
- BUILDS PROCESS STRUCTURE - 
- LOADS WSR’s 


- CLIMB’s TO INITIAL ENTRY POINT 
(GENERATES DYNAMIC LINKING FAULT) 
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CONSTRUCTION OF VIRTUAL ENVIRONMENT (CON‘T) 


DOMAIN OR SEGMENT NAME 


DYNAMIC LINKER 


ENTRY OR SEGMENT DESCRIPTOR 


INVOCATION 


- DYNAMIC LINKING FAULT REFERENCING A DOMAIN 


- REFERENCE TO A SEGMENT EXTERNAL TO THE B-UNIT 


FUNCTIONS 


- USE SEARCH RULES TO DETERMINE THE ORDER OF WSRs TO 
SEARCH 


- SEARCH DIRECTORY OF DOMAIN AND SEGMENT NAMES FOR EACH WSR 


- IF B-UNIT CONTAINING DESIRED DOMAIN OR SEGMENT NAME HAS 
NOT BEEN LOADED, THEN ACTIVATE B-UNIT — 
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CONSTRUCTION OF VIRTUAL ENVIRONMENT (CON‘T) 


B-UNIT 


= 
W 
eo 


B-UNTT ACTIVATION 


LOADED B-UNIT 


INVOCATION 


-~ FROM DYNAMIC LINKER 


FUNCTIONS 


- FIX WSR VALUES IN ALL DESCRIPTORS 


- IF NOT FIRST B-UNIT IN WS, THEN RELOCATE VIRTUAL ADDRESSES 


INITIALIZE B-UNIT ON BACKING STORE FILE 


ACQUIRE REAL MEMORY WORKING SET 


RESOLVE SEGREF’S VIA DYNAMIC LINKER 
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DOMAINS 


Do 


SEGMENTS 


S] 


B-UNIT LIBRARY 


DOMAINS 


Dz 


SEGMENTS 


FILE SYSTEM LIBRARY DIRECTORY 


B-UNITS 


DOMAINS 
Du 
Dr 
Dg 
SEGMENTS 


52 
S3 


AFTER ASSIGNMENT OF LIBRARY TO WORKING SPACE: 


DOMAIN DIRECTORY 


By 
By 


SEGMENT DIRECTORY 


S] By 
S9 Bz 
S3 Bz 
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DYNAMIC LINKING 


DOMAIN DIRECTORY DOMAIN DIRECTORY 
1 X B ENTRY 
Ny, By Le 

Dz Bo SE. 

Diy B3Csé#é:DD LS (X) 

Dr Bz =SC#;.YWD 

DE BzCtééC;«DD, 

SEGMENT DIRECTORY Dy Dz 
Sy Bi 

39 BzCtC«SS«WDD 

Sz Bz oS 
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- MACRO-STRUCTURE - FUTURE WORK 


o DEFINE FORMATS FOR A-UNIT, B-UNIT 
DEFINE WORKING SPACE FORMAT 

DEFINE SEARCH RULES FOR DYNAMIC LINKING 
DEFINE REQUIRED JCL 

DETAIL SHARING CONTROL MECHANISMS 


0 


0 


0 


~ COMPLETE SPECIFICATIONS FOR: 


A-UNTT MERGER 
B-UNIT BUILDER 
B-UNIT MERGER 
B-UNTT ACTIVATOR 
PROCESS INITIATION 


SPECIFY DYNAMIC LINKING MECHANISMS 

SPECIFY DYNAMIC LOADING MECHANISMS 

DEFINE SYSTEM TABLES AND DIRECTORIES REQUIRED TO SUPPORT SHARING 
& LINKING MECHANISMS 

SPECIFY USE OF FILE SYSTEM FOR LIBRARIES 

TASKING 
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INTERNAL ENVIRONMENT 


ADDRESS VALUE REPRESENTATION 
- IMPORTANCE 

- OPTIONS CONSIDERED 

- COMPARISON 

- CONCLUSION 


INTERNAL STRUCTURES 
- SOFTWARE STACK 
- PROCEDURE SEGMENT LAYOUT 


PERFORMANCE 
- NON-ADP 
- ADP 


FUTURE WORK 
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REPRESENTATION OF ADDRESS VALUE IS IMPORTANT BECAUSE: 


HIGH ORDER LANGUAGES USE ADDRESS VALUES FOR: 


POINTERS EXCEPTION PROCESSING 
ENTRIES STACK CONTROL INFO 
LABELS PARAMETER REFERENCING 
ALTERNATE RETURN ARGUMENT LIST BUILDING 
BASED STORAGE LOCATE MODE I/0 


OUTER BLOCK REFERENCING 
CONNECTION TO RUNTIME 


BECAUSE THESE FACILITIES ARE WIDELY USED, THEY MUST BE IMPLEMENTED EFFICIENTLY, BE 
EASY TO USE, AND MUST BE SUFFICIENTLY POWERFUL TO SUPPORT MULTIPLE HOL USE. 
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ADDRESS VALUE OPTIONS CONSIDERED 
REQUIRES 


1, NSA POINTER |BIT ADDR _| SEG ID | LINKAGE SEGMENT 


BYTE BDRY | FLAGS 
BASE 


| BIT ADDR 

BIT ADDR "CANONICAL" DS 

SEG INDEX | +1 ODR 

4, SUPER POINTER BIT ADDR "CANONICAL" SUPER DESCRIPTOR 
+1 ODR 


2. DESCRIPTOR 


+ 


AR VALUE 


DESCRIPTOR SEG 


5, TABLE INDEX 
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EVALUATION OF ADDRESS VALUE REPRESENTATION 


CRITERIA i DESC.  JABLE SUPER 
1. STORABLE IN DATA SPACE | Y N Y Y 
2, UNIFORM REFERENCE TO PARAMETERS INDEPENDENT Y Y Y N 

OF DOMAIN PACKAGING 

3, RETAIN IDENTITY WHILE IN ODR Y Y N Y 
4, SUPPORTS SEGMENT-LEVEL PROTECTION ' ¥ Y Y N 
5. CAN ADDRESS > 256K N* = Y y Y 
6. CAN HAVE > 1024 SEGMENTS | N* Y Y Y 
7, RELATIVE HIGH PERFORMANCE | N?  =Y N Y 
8, VALID ACROSS DOMAINS N Y N N 
9, BIT LEVEL ADDRESSABILITY Y Y Y Yo 


seee=aes ABOVE THIS LINE, N IS UNACCEPTABLE 
“CAN BE IMPROVED BY HARDWARE CHANGE 
? ~~ SOME HARDWARE IMPROVEMENT POSSIBLE 
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CONCLUSIONS ON ADDRESS VALUE REPRESENTATION 


CAN'T USE DESCRIPTOR + OFFSET — 
- NOT STORABLE IN DATA SPACE 


CAN'T USE TABLE INDEX 
- LOADING TO ODR LOSES SEGMENT NUMBER 
- REQUIRES SEVERAL INSTRUCTIONS TO LOAD 


CAN'T USE SUPER POINTER 
- NO WAY A PROCEDURE CAN TELL WHETHER TO REFERENCE PARAMETERS RELATIVE TO 
THE SUPER DESCRIPTOR FOR THE DOMAIN OR RELATIVE TO THE PARAMETER STACK 
- COMPROMISES INTRA-DOMAIN SEGMENT PROTECTION, SINCE ALL DATA REFERENCE IS 

THROUGH ONE DESCRIPTOR 


ONLY ALTERNATIVE LEFT IS NSA POINTER 
- DESPITE PERFORMANCE PROBLEM 
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SOFTWARE STACK 
FACH DOMAIN HAS A SOFTWARE STACK TO CONTROL INTRA-DOMAIN TRANSFERS AND 
EXCEPTION PROCESSING 


ROOT FRAME 

- CREATED ON DOMAIN ENTRY 

- POINTS TO EXCEPTION PROCESSING ARRAY 
- CONTROLS STACK SPACE 

- UPDATED DURING EVERY CALL 


BASIC FRAME 

- REGISTER SAFE STORE 

- PARAMETER HANDLING 

- AUTOMATIC STORAGE SPACE 
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SINGLE PROCEDURE SEGMENT 


ENTRY 
POUT ccna 


ENTRY 
POINT, 


PROCEDURE. & 
pa iedee 


ENTRY POINT 
DATA 


PROCEDURE & 
CONSTANTS 


POINTER 
AREA. 


PROCEDURE SEGMENT LAYOUT 


MERGED PROCEDURE SEGMENTS 


POINTER 
AREA A 


PROCEDURE A & 
ENTRY POINTS 


POINTER 
AREA BR 


| PROCEDURE B & 
ENTRY POINTS 
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URE WOR 


STACK FRAME FORMAT & CONTENT 

STANDARD CALLING SEQUENCE 

ARGUMENT LIST FORMAT 

EXTERNAL ENTRYPOINT CONVENTIONS 

ADDRESSING CAPABILITIES WITHIN OBJECT UNIT 

PLS VS, CANONICALIZING OF LINKAGE SEGMENT 

HOW A PROCEDURE FINDS ITS LINKAGE 

HANDLING OF LARGE ARRAYS 

EXCEPTION HANDLING 

SUPPORT OF ON UNITS AND SIGNALLING 

SEGMENT LEVEL SHARING 

OPERATOR SEGMENT ADDRESSING, SHARING, LOCATION 
RUNTIME SYMBOL TABLE & DATA DESCRIPTION SCHEMA 
DYNAMIC LINKING SUPPORT 

1/0 SYSTEM INTERFACE 

TASKING SUPPORT 

CALL/CANCEL SUPPORT 

PRIORITY SEGMENTATION 
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WE HAVE EXHAUSTIVELY INVESTIGATED THE USE OF THE NSA POINTER AS THE ADDRESS 
VALUE. 


PERFORMANCE MAY BE A PROBLEM, 


A UNTFORM SYSTEM MICRO-STRUCTURE (CALLING SEQUENCES,ETC.) IS BEING INVESTIGATED 
BASED ON THE USE OF NSA POINTERS. 


A FIRST CUT HAS BEEN MADE OF THE DEFINITION OF SYSTEM MACRO-STRUCTURE 
(JCL, ETC.) | 


MUCH DETAILED WORK REMAINS FOR BOTH AREAS, 


4/18/80 


